I think your question is, in part, about how to deal with "one-of"
authentication requirements, in PAM.
PAM is rather weak here as the require/requisite/sufficient/optional
stuff is not enough. A boolean expression approach would be better, but
for now the only thing you can do is play with required/... and, where
you control module source, PAM_IGNORE. Thank goodness for PAM_IGNORE.
That, in fact, is what we've done. Look at the PAM_KRB5 in SourceForge
(same repository as LinuxPAM), specifically in the devl branch. One of
the options accepted by its auth method is "ignore_unknown_upn" which
causes PAM_KRB5:pam_sm_authenticate() to return PAM_IGNORE when PAM_USER
has no Kerberos account. This option allows the following
configuration:
auth required pam_krb5 ignore_unknown_upn
auth optional pam_unix use_first_pass
Meaning that users must have a Kerberos account or a Unix (local or as
per-NSS setup) account.
Watch out, it's possible to spoof error AS_REPs so a user could skip
Kerberos password validation, but the user must still have a valid Unix
account.
Now, you still want to stack in a module that requires Kerberos
credentials, but which does not provide authentication, here's how
you'd do it:
auth required pam_krb5 ignore_unknown_upn
auth optional pam_unix use_first_pass
auth required pam_xyz use_first_pass
where PAM_XYZ:pam_sm_authenticate() always (or almost always) returns
PAM_IGNORE.
And you can keep playing such games till you find the setup that matches
your needs.
The problem is that to get this right you need modules that have an
option to force them to return PAM_IGNORE from pam_sm_authenticate()
sometimes or everytime. And this usually means writing your own modules
or modifying an existing module's source.
I'd much rather have a PAM configuration system whereby you specify: a)
the order of module method calls, b) an expression for evaluating
a method return value based on the module's return values. Modules would
get called in the order defined in (a) but only as needed to evaluate
(b).
E.g.,
auth pam_abc
auth pam_xyz use_first_pass
auth result (pam_abc && (pam_xyz || success))
or
auth pam_abc
auth pam_xyz use_first_pass
auth result (pam_abc || (pam_abc == user_unknown && pam_xyz) || perm_denied)
and so on. It would also be nice to be able to check several PAM items
in such expressions (e.g., (item(user) == root && item(tty) ==
"/dev/console" && pam_unix && success)). Error names short-circuit the
expression, returning immediately; tokens named pam_* refer to the
return value of the given PAM module, and so one.
And, frankly, it would be nice if setcred could be specified separately
from auth.
NOTE: Linux-PAM 0.75 and Solaris PAM will always call a module's
pam_sm_setcred() method regardless of the return value of it's
pam_sm_authenticate() method. I think earlier versions of LinuxPAM
may not. Check the docs (or source, or experiment).
NOTE: PAM_KRB5, devl version, in the SourceForge CVS has some bugs known
to us; we will commit fixes this week.
Cheers,
Nico
On Sat, May 12, 2001 at 05:14:20PM -0400, Sam Hartman wrote:
>
>
> So, both the Linux-PAM and Solaris documentation tell authors to call
> pam_open_session before pam_setcred. I don't understand why this
> would ever be useful and have examples of cases where it would be a
> bad idea.
>
> In particular, I'm looking at the interactions between Kerberos
> modules and session modules that depend on access to network
> credentials. It seems that the Kerberos module should make tickets
> available (write them out to disk as the user) in the pam_setcred
> call. This seems an appropriate use of the call and works quite well
> in most cases.
>
> But then it seems that it would be a session level activity to mount a
> homedir, or create a homedir, or in my case let AFS know about tokens.
> None of these activities have anything to do with authentication, but
> all of them could depend on having access to network authentication
> made available in setcred. For example, I could be using a networked
> filesystem with authentication to mount the homedir. I could desire
> to log into a database to get information on the initial contents of
> the homedir, authenticating to the database with the network identity
> of the already authenticated user. In the AFS case I need the
> credentials to convert them into tokens.
>
> I'll take a moment to counter the argument that AFS tokens have
> something to do with authentication. It is true that Transarc ships a
> PAM module that uses AFS tokens for authentication. This
> authentication is very weak (about the same level as NIS) because the
> client never authenticates the identity of the AFS server. In the
> case where you have Kerberos infrastructure and are just using AFS as
> a filesystem, you don't care about AFS for authentication, and just
> want to make the credentials available to the kernel.
>
> So, I am maintaining a module (libpam-openafs-session) for Debian that
> attempts to get AFS tokens. Previously it only worked as a session
> module, but I'm trying to add authentication support to the module for
> setcred. I'm running into the annoying problem that there appears to
> be no valid configuration for the module.
>
> I really want the Kerberos module to be sufficient because I want to
> allow users with local accounts to use pam_unix.so, so I need to make
> pam_unix.so be more than just optional so people with neither local
> accounts nor Kerberos authentication will fail. However, the openafs
> auth setcred call needs to happen after the Kerberos setcred call so
> it can get to the credentials. Sadly, if the sufficient Kerberos
> module succeeds no other modules will be tried. To me, this is a
> fairly strong argument that AFS tokens cannot be an authentication
> activity--you want them to get set up even if you have already
> established sufficient authentication beforehand.
>
>
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
--
