Ok, after just doing a bit of coding with the Python bindings for PAM, I'm
all for this - I'm writing a PAM & LDAP LoginManager application for a Zope
site, and it uses HTTP Basic authentication (over SSL, of course). Now, the
problem is that potentially the PAM stack can ask for anything. That's fine,
and I understand and agree with the current design limitations in PAM that
make that so. However...
I can't get around that easily - *if* the PAM stack (whatever it may
contain) will be happy with a username/password pair (which is all I can
supply) then I'm ok, otherwise I fail. *But* - there's no uniform way of me
setting the password in the stack. I have to parse a text string returned by
the module looking for m/pass\s*word|pass\s*phrase/i - that can't be right.
>From what I can see:
case PAM_AUTHTOK:
/*
* The man page says this is only supposed to be available to
* the module providers. In order to use this item the app
* has to #include <security/pam_modules.h>. This is something
* it is *not* supposed to do with "Linux-"PAM! - AGM.
*/
{
char *_TMP_ = pamh->authtok;
if (_TMP_ == item) /* not changed so leave alone */
break;
pamh->authtok = (item) ? _pam_strdup(item) : NULL;
if (_TMP_) {
_pam_overwrite(_TMP_);
free(_TMP_);
}
break;
}
i.e. It *will* work from an application. Are there good reasons to not let
an application set the "password" as it sees it? I know about the argument
that the AUTHTOK might not be valid, but IMHO, that's what use_first_pass
versus try_first_pass are there for - the administrator has to configure the
stack to work appropriately, and the application writer must specify the
requirements of the stack so the administrator can do that.
Thoughts?
Regards,
Phil
+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+
-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@ubsw.com]
Sent: 14 December 2000 17:47
To: pam-list@redhat.com
Subject: Re: Passing password through a PAM-API
The conversation function is provided by your app. If the app knows the
answer to a prompt then it need not engage in any I/O...
On the other hand, if the app knows the user's password before getting
to PAM (apps like XDM would, as they prompt for username and password in
one go), then you have a bit of a problem as LinuxPAM does not allow the
app to do a pam_set_item() on the PAM_AUTHTOK item. This is very
unfortunate. I brought this up recently here and had no response,
probably because I didn't include a patch to implement what I was
proposing; perhaps I will, thnough not soon.
Nico
On Thu, Dec 14, 2000 at 10:38:54AM -0600, Benjamin S Vera-tudela wrote:
> Well, thank you Michael and Steve for your prompt replies .....
>
> I still have one problem though .... the application I mentioned is
> primarily going to be used not from the command line. This application
> provides an API to be used by testers to write testcases, and use this API
> to start, as an example, a process as a different user. However, we would
> like to make sure they can start a process as another user by
> authenticating them (i.e., by making sure they know the password of the
> user they want to start the process as).
>
> So, for example, we have an API that takes a string that tells the app
what
> to do on what machine, something like:
>
> unsigned int submit(char *machine, char *service, char *request)
>
> where request can be something like:
>
> "start process xclock asuser benjamin passwd mypwd" -- I have italized
> user options
>
> Now, we know that this is "dangerous" because the string is stored in the
> app in ASCII. using the passwd/crypt or shadow/crypt authentication model,
> we can crypt mypwd and pass the encrypted version (although we know this
> can be broken too). the problem with the current conversation model
> provided by pam is that the app would block waiting for input and would
> defeat the entire purpose of the app which is "automation". this app is
not
> intended to be bullet proof. all we are trying is to provide some way of
> authenticating users (ideally using the platform's default protocol, like
> shadow/crypt on most unices except linux) just to ensure they can start a
> process as another user. in fact, we are also giving the option to
> configure the app so that it skips authentication if they so desire, but
we
> want people to have a choice on this respect. since we plan on linux being
> our most widely used platform, and most linux boxes authenticate through
> PAM, we are pretty much stuck (at least until now). we would like to avoid
> telling people to change their authentication protocol. we want to make
> things as simple as possible for the user, but still allow some sort of
> security mechanism just to avoid accidental use as instead of malicious
> use.
>
> any ideas?
>
> Benjamin S. Vera-Tudela
> Software Engineer
> IBM e-boss - Austin, Texas
> Phone: (512)-838-8246
> E-Mail: bveratudela@us.ibm.com
>
>
>
> Michael Gerdts <Michael.Gerdts@usa.alcatel.com>@redhat.com on 12/14/2000
> 10:04:24 AM
>
> Please respond to pam-list@redhat.com
>
> Sent by: pam-list-admin@redhat.com
>
>
> To: pam-list@redhat.com
> cc:
> Subject: Re: Passing password through a PAM-API
>
>
> On Thu, Dec 14, 2000 at 08:33:11AM -0600, Benjamin S Vera-tudela wrote:
> > $ myapp login [user] passwd [password]
> >
>
> Are you sure that you really want to do that? Anyone else on the box can
> then use ps(1) to get passwords of others.
>
> > Second, I noticed in the PAM website that an example application
requires
> > application writers that wish to use PAM to add a couple of lines in the
> > /etc/pam.conf file that look like this:
> >
> > [service name] auth required [pam auth library name]
> > [service name] account required [pam acct library name]
> >
> > Is it possible to avoid having to do this? I believe that one option is
> to
> > provide your own authentication module (library) -- in the same way
> login,
> > su, and other Linux apps do --, and link your application to that
module.
> > Are there any other options? Having to provide another library in my
> > application is the last option, so modifying the pam.conf file is
> probably
> > ok, but if there is an option that does not require providing a new
> library
> > and changing the pam.conf file, I would be glad to know about it.
>
> Most pam implementations pay use other (OTHER for HP-UX) as a catchall for
> apps that do not use any special library. If all of your apps only needed
> pam_unix, the following would be all that you really need
>
> other auth required /lib/security/pam_unix.so.1
> other account required /lib/security/pam_unix.so.1
> other session required /lib/security/pam_unix.so.1
> other password required /lib/security/pam_unix.so.1
>
> Mike
>
>
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
>
>
>
>
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
--
_______________________________________________
Pam-list@redhat.com
https://listman.redhat.com/mailman/listinfo/pam-list
