--On Monday, March 17, 2008 05:02:46 PM -0800 Gary Winiger <gww at eng.sun.com> wrote:
>> Sorry; but I'm going to return us to this flamewar... > > Let's not continue that. I did want to correct a misconception > on what screenlocks do, however. Again, you are assuming a Sun-centric worldview, and an idealized one at that. >> This is an excellent reason for the process which calls PAM _not_ to be >> an external helper. As noted, screensavers don't open sessions. They >> do call pam_authenticate(), and may also call >> pam_setcred(PAM_REFRESH_CRED) > > First they audit that they are locking. This requires privilege > in most (all) systems. > For unlocking they present a trusted path to the user. This > requires some special rights on most (all) systems. xscreensaver, as shipped from the upstream source, does no auditing which requires privilege. I'm not sure it even logs to syslog, which certainly requires no privilege. If Solaris's auditing model requires privilege in order to audit events, IMHO that is a bug. > They then pam_authenticate(), pam_acct_mgmt() -- which may return > PAM_AUTHTOK_EXPIRED, if so they call pam_chauthtok() -- My analysis found that xscreensaver either calls pam_acct_mgmt, but ignores its result. We assume that other unknown applications will behave in the same way. Our PAM module has configuration to handle this case by failing pam_authenticate when the user's password is expired. Because PAM applications are not all provided by Sun or even by some other OS vendor, and because many of them are written by people unfamiliar with PAM using poor documentation (typically, for Linux-PAM, which may make it worse), there are certain assumptions which it is simply unsafe to make about an unknown application. For example, it is unsafe to assume that pam_setcred and pam_open_session will be called in a particular order, or even that they will both be called, and it is unsafe to assume that pam_acct_mgmt will be called and its return value obeyed, especially when it is PAM_AUTHTOK_EXPIRED. It is also unsafe to assume that an unknown application will provide a real converstion function; for example, xscreensaver does not. > call pam_setcred(PAM_REFRESH_CRED), potentially all of these > may require on most (all) system. For some modules, calling pam_setcred(PAM_REFRESH_CRED) without privileges is not very interesting. For others (e.g. pam_krb5, as I and others have mentioned), it is extremely useful. > Finally they audit the screen unlock. This requires privilege > in most (all) system. See my comments above about auditing. The point is, perhaps screenlockers and PAM applications in general would behave as you suggest in an ideal world, but they do not do so today, and as an operator who extends Solaris _and other operating systems_ by providing PAM modules and applications, I find the "must be privileged" requirement very annoying. BTW, I also find the Solaris requirement that PAM module objects be owned by UID 0 to be extremely annoying. This prevents my builds from running automatically, because it is necessary to acquire privilege not only to configure the PAM stack (which is a once-per-machine cost I can accept), but also to chown the newly-compiled module before the tests can be run. I do hope this antiquated restriction has been removed. -- Jeff
