[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM, When?

> So, hopefully that topic won't have died out on this list. Me, not being
> someone who has ever coded apps for PAM (ok, coded apps in C for Unix at
> all, beyond undergrad course stuff), I can't offer anything to make the
> ball roll, but am hoping someone will post with their thoughts about what
> directions the code currently known as Linux-PAM can be taken to make it
> cooler. =)

what will make Linux-PAM )referred to as PAM below, for short) cooler is
one or more of these things:

1) PAM security negotiation to be abstracted from PAM itself.  take the
example of the SMB protocol for NT5: SMBnegprot request now has an
"EXTENDED_SECURITY" capabilities flag.  if set and the server responds
that it supports it, the session goes into "abstracted security" mode. 

what then follows in the SMBnegprot response is a "security blob" (char*
sec, int length), which is opaque to the SMB server itself.  the client
then sends an SMBsessionsetupX with again, a "security blob" (char* sec,
int length).  if the SMB server is told that security negotiation is not
yet over, it responds in the SMBsessionsetupX with
"STATUS_MORE_PROCESSING_REQUIRED_ error code.  the client is then expected
to do further SMBsessionsetupX calls until the server is told by whatever
security is being used that it is finished.

this is described in detail in the latest cifs draft rfc proposals, to be
found in ftp://ftp.microsoft.com/developr/drg/CIFS.

i understand that microsoft intends to use SPNEGO over SMB, and they will
be negotiating to use their own version of kerberos 5 or the old-style
NTLM 8-byte challenge / 24-byte response.

why do this?  because a) microsoft is and b) because a simple "give me the
plain-text password" isn't enough.  in some instances you may not _have_
the plain-text password: you may have a plain-text equivalent password;
you might not even have the right to authenticate the user, but you know
someone who can, therefore you can either refer the PAM module to the
correct host _or_ you can do pass-through authentication, but without ever
knowing the details of what the authentication process is doing.

2) an extension to PAM to obtain user information and group information,
abstracted sufficiently so that you no longer have to store /etc/group or
any other authentication information on local machines _at all_.

oh, ok, that's a bit extreme (but it _should_ be possible): let me say
that again: other than local accounts, it should be possible to seamlessly
supplement users and groups on a local machine without having to add user
and group information to the local security databases.

why do this?  because the PAM philosophy is a good one: i think it should
be extended to cover complete authentication, allowing administrators to
choose a completely different set of authentication modules on a per-host
or per-user basis, and hey, wow: they can still access all their files.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []