Darren J Moffat wrote: > Alan Coopersmith wrote: >> Darren J Moffat wrote: >>> What other PAM modules (from Linux-PAM or other places) would you >>> like to see included in OpenSolaris distros (specifically in Solaris >>> Express and the Indiana project distro) ? >> >> From the screensaver point of view, the one Linux-PAM'ism that's bitten >> us most lately is their changes to allow programs to call PAM without >> root privileges when checking the current user's authentication (i.e. >> in a unlock dialog), so that their screen lock doesn't have to be setuid >> root and can use GTK without the split personality we've had to put into >> our xscreensaver, and then fix the dozens of bugs it causes. >> >> Their pam_unix module calls a setuid helper program to get your shadow >> entry when needed - not sure if any other modules have or need privs. > > Which in my opinion is fundamentally broken behaviour. While it works > for the pam_authenticate() call in that specific module in general > running pam_authenticate() and pam_setcred() without privilege just > won't work for some modules. For example the Solaris pam_unix_cred > module won't be able to do its job properly (it won't be insecure but > it won't do what it is supposed to do) - while this doesn't actually > matter in the screensaver case it does in the general case. > > I understand the desire not to run the screensaver program with > privileges but the component that calls libpam(3pam) API needs to be > running with privilege. It isn't and shouldn't be up to the modules > to work out what privilege they need. > > Unfortunately this was never well documented in any PAM documentation > so I can easily understand how the setuid helper for authentication > was implemented. > I believe the issue is in the evolution of GUI libraries (specially libgtk) whereas PAM stuff was designed for more of a text based authentication. PAM to me seems primarily as a concept of doing authentication, and it uses delegation, i.e. delegate the authentication to pluggable modules. Or you could say outsource authentication to modules :-)
Now, since you are outsourcing, and dont provide your own GUI lib, people went ahead and outsourced the setuid limitation, so they could use libgtk. We at Sun, either have to provide a secure libgtk (which can be run with root privs), or fill in the holes present in setuid helper programs. I am not sure there is a third option. Or is there?( current xscreensaver is a dead end) Guaranteeing that libgtk is safe to be used by root with all the extensions that keep getting added to it and perhaps could be loaded at run time is not possible. Perhaps we could just make a subset of libgtk that only does what we need in gnome-screensaver and accessibility libs of libgtk. This still would be a big mess but perhaps dooable. What exactly is broken in the setuid helper programs that red hat currently uses. I have tried to understand the shortcomings of helper program but never quite understood its limitations. If you guys point me to exactly what is broken, perhaps we try to fix the broken parts? --mahmood cc'ing Brian since he also put his efforts in evaluating helper setuid programs.
