On Mon, Mar 17, 2008 at 07:49:05PM -0400, Jeffrey Hutzelman wrote: > Sorry; but I'm going to return us to this flamewar...
Oh no! > --On Thursday, March 06, 2008 02:43:00 PM -0600 Nicolas Williams > <Nicolas.Williams at sun.com> wrote: > > >PAM modules may require any and all [zone] privileges. Using PAM > >requires all [zone] privileges. > > This is a Solaris-ism. You need to get out of your Sun-only box and pay > attention to the rest of the world for a bit. Usually I accuse Linux folks > of being myopic in this way, but if the shoe fits... It may be a Solaris-ism, but it's one that makes a lot of sense. The same analysis went into our version of privsep for sshd. Compare the two approaches for simplicity... > [...] > The easiest way to accomplish this is to insure that PAM modules, or at > least those which make sense in this context, can support pam_authenticate > and (where appropriate) pam_setcred(PAM_REFRESH_CRED) even when called > without privilege. For something like pam_krb5 authentication requires privilege (to read the system keytab). For something like pam_unix_auth authentication requires privilege (to read /etc/shadow). Etcetera. I know, I've heard MIT krb5 core folks talk about having a daemon to provide ticket-validation-with-keytab services as am approach to separation of privilege in authentication. How many such daemons (or services, say, in an ubber-daemon) should we need? Also, if it establishing a trusted path between the X11 display and the screen lock programs requires executing the latter with privilege then why bother? (To be fair, today I think it would, but once we have validated execution maybe not.) The need for privilege while doing the things that PAM modules do is unavoidable. Privsep for PAM: to proxy PAM calls (though things like pam_unix_cred make that difficult) or to do it inside each module? Alternatively: accept that programs that use PAM require all privilege and must be part of the trusted base, then move along. This is what Solaris engineers chose long ago, and it's a choice that we who inheritted it stand by. > A screensaver is an application, though a slightly specialized one. Users > should not be restricted to running applications which ship with the OS or > were "blessed" by a system administrator. Restricting me to running > gnome-screensaver is insane. It's not insane. Yes, users can make their own screen lock programs. I gather that's what you meant. "Not letting me run my own screen locker is, like, fascist dude!" :) Hmmm... We don't do user proximity detection, so we don't audit when users get up and go to the restroom, say. If users can run their own screen lock programs then where do we audit the lock/unlock? In the X11 server, I'd think, since in that scenario it's the only one that can know about the lock/unlock and can have the required privilege. Nico --
