Jim Colten schrieb: > Our local Solaris ambassador has suggested I post this here. > > Let me start with one bit of info. We use a two factor > authentication product named SafeWord (from Secure Computing). Our > unix authentications happen via a PAM module provided with SafeWord. >
> [...] I defined some new userids and granted them all privileges (mine > is named "jcolten"). But when I logged in to jcolten I had only > BASIC privileges. HUH????? > > I also learned that if I use su to become that userid ... su - > jcolten .... I get all the privileges! DOUBLE HUH???? > > And if I login via SSH using publickey authentication (which is early > in the list of authentications and bypasses two factor) I get all > the privileges.. DITTO HUH????? > > After a bunch of digging I learned that when I login via SSH using > PAM authentication, privileges get setup by pam_unix_cred.so.1, > called by PAM during the authentication process. True. Privileges are considered credentials and are set up during pam_setcred(3PAM) processing. > Similarly, "authorizations" are handled by pam_unix_auth.so.1, also > called by PAM. Not true. "authorizations" are associated to users, not to processes, so they don't need to be set up explicitly during login. And pam_unix_auth handles 'auth'entication, not 'auth'orizations. It is the module that does the ordinary password verification for authentication. This happens during pam_authenticate(3PAM) processing. > The pam.conf setup we use to call SafeWord bypasses > pam_unix_cred.so.1 and pam_unix_auth.so.1 .... and there does not > appear to be a workable PAM stack that avoids that without causing a > lot of user confusion. > I have to do some guessing about your PAM stack and the SafeWord PAM module here. I assume you have the SafeWord module set up to be 'sufficient' (or 'binding'), so PAM stack processing stops when the module returns success. This is the proper thing to do, if you want to try SafeWord authentication first and have password-based authentication as a fallback. In that case you also have pam_unix_auth.so.1 below the SafeWord module on the PAM stack. I also assume that the SafeWord module returns success from its pam_sm_setcred(3PAM) invocation, so that pam_setcred stack processing stops there, at the same place as pam_authenticate stack processing (because pam_authenticate and pam_setcred share the 'auth' stack. If you now want to have Solaris credentials applied (by pam_unix_cred.so.1) in all cases, including SafeWord logins, you simply need to move pam_unix_cred.so.1 up in the 'auth' stack, so it is invoked before the SafeWord PAM module. You can leave the pam_unix_auth.so.1 module where it is, because it appears to be in the right place - and affects only authentication. Have you tried this? Why do you think this would not be a workable PAM stack or cause user confusion? > Using DTrace Toolkit's opensnoop I see that the su command also seems > to use those two Pam modules when changing effective UID to the new > user. Ditto for SSH logins using public key auth. > SSH login (except keyboard-interactive) is a bit special, as it does not use PAM for the original authentication, i.e. it skips pam_authenticate and invokes only the other PAM functions. > Those three "facts" seem to explain what I'm seeing when I do and > don't get privs. PAM's rather limited "stack model" for describing > how a service gets authenticated does not provide us with a way to > accomplish a user friendly two factor login process and still get > the services of pam_unix_auth.so.1 and pam_unix_auth.so.1. > If moving up pam_unix_cred towards the top of your stack doesn't work, you might need to show your pam.conf for further advice. > I'd like to make the case that PAM is not the place to setup > privileges and authorizations, primarily because: > > 1. It is generally recognized that "identity" and "authorization" > (which includes both Solaris privileges and Solaris authorizations) > are separate things that should never be joined at the hip by the > method in which they are implemented. PAM has parts that are not mere authentication. In particular it has well-known uses for creating per-process or per-session credentials that derive from the completed authentication. Solaris privileges are a per-process property which needs to be initialized to a user-specific value at login - seems a good fit. > 2. Solaris 10's approach makes an opportunity to make the result of > an "ordinary SSH login" to a user yield results very different from > what "su - userid" yields. Only if you use many different authentication policies. I have to agree though, that the coupling of authentication and setting of credentials (both are controlled by the same 'auth' stack) requires extra thought to make sure you get similar credentials set up even though you use different authentication mechanism for different services. > 3. Similar with "ordinary SSH login" vs publickey SSH login > IMHO this very example show that it may well be desirable that you get different levels of credentials depending on how strong an authentication method you used. - J?rg -- Joerg Barfurth Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
