On Thu, Mar 06, 2008 at 03:02:54PM -0600, Brian Cameron wrote: > >PAM assumes all privileges are required. I think that's an assumption > >best left alone. > > Oh, I agree. However, the Linux community obviously thinks differently > here. They think that using least privilege in the PAM lock screen case > is a good idea. > > I am not sure it is worth the time to argue the merits of one or the > other approach with the Linux community. It's probably not constructive > for either to call the other "broken", for example. After all, we are > not going to invest the time to fix the Linux implementation if we don't > like it, so why criticize.
I most certainly did not call the LinuxPAM approach "broken." It's a different approach. My point is that the assumption/requirement of all privs by PAM is just too embedded in Solaris. And while we might consider changing it, I'd rather that integration of some screen lock program of Linux lineage not be the main reason for doing it. > That said, since the lockscreen programs we want to use on Solaris > includes ones that also need to work in Linux environments (such as > gnome-screensaver as xscreensaver), we should understand our assumptions > to the point where we can carry intelligent dialog with our Linux > partners about why we do things differently, etc. People like the > gnome-screensaver maintainer tends to ignore our requests for help when > we can't explain why we do things the way we do. Part of the problem > here is probably just that people in the JDS and Xserver team are trying > to carry on the dialog with the gnome-screensaver people, rather than > people who really know the ins and outs of the security models. Sure. I believe it should be possible to write a portable screen lock program that fits either model. In particular, it should be possible for a screen lock program that fits the Solaris model to run fine on Linux. FWIW, we've differed with others when it comes to least privilege in other areas too. For example, we deemed OpenSSH's appropach to privilege separation prior to the end of authentication to be too cumbersome and not sufficiently valuable, so we ditched it. Our model is much simpler as a result (arguably we could also separate the SSH packet layer, that is, the crypto and compression code, up to the end of user authentication; our model doesn't prevent it -- we just never implemented it). Nico --
