Mahmood Ali - Sun Microsystems schrieb: > Darren J Moffat wrote: >> Mahmood Ali - Sun Microsystems wrote: >>> 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? >> The whole architecture of it is broken. Sure it "fixes" that one >> module but what about all the other possible modules in the PAM stack >> that are needed to authenticate/setcreds etc ? >>
Maybe it would be helpful to have a generic helper program and library that provides a remote version of the PAM API over a secure, local RPC connection. The client would still need to get privileges first and then drop them, but the mechanics of the IPC protocol and the privileged helper wouldn't need to be reinvented every time. That would surely simplify getting rid of the privilege issue in more client programs. It would not solve the problem of 'PAM clients' that don't implement a proper conversation callback, but instead assume a simple user/password dialog. But that is a different issue and something maintainers might be more open to than inventing their own scheme to solve the privilege problem. > You are right, I just remembered we need to have actual conversation > with the PAM modules, that would mean listening what the module is > asking and showing that to the user and then getting user's response and > sending it to the PAM module. And this is the part that the gnome > community at large does not entertain. Mostly, they assume > authentication is going to be just username/password and do not do any > conversation back and forth. This is where the disconnect between us and > gnome community is. > > But, what is puzzling is how come they have not discovered this > brokeness in their code? They probably know about some or even most of it. But still their code isn't up to what some real life PAM stacks are doing. The approach to addressing the issues seems piecemeal. For a concrete example of what is broken, I recently looked at gnome-screensaver and it takes a trial and error approach with unjustified assumptions: - First it shows a password input box, which presupposes that the first conversation callback it will get, will be for a password-style textual authentication token. - Next, when this dialog is closed (iirc), it runs pam_authenticate in-process, without privileges. I don't know offhand how it reacts on extra or unexpected conversation callbacks. It might do something with them, because here it has the GUI available. - If that PAM invocation fails, it assumes that this is due to lack of privileges it runs the same PAM stack again in a privileged helper that needs to be passed the user name and password and doesn't accept any other inputs and can't do conversation callbacks. (This duplicate invocation may also be a problem with some PAM modules, that have side effects.) And this just covers the authentication step. I don't know how/where they fit account management (with possible need to update an expired password) and credential establishment into the picture. > And what can we do to get them to understand > this better? Do we have pam stacks that would break their code, passwd > expired case, etc?? > - PAM stacks that don't require textual user input don't work with the described approach (e.g. some smartcard or biometrics based stacks could work that way). - PAM stacks that have extra modules that request multiple textual authentication tokens don't work. - PAM stacks that need to issue prompts for out-of-band input (e.g. "Insert smartcard now") don't work. - As you indicate, password-expired scenarios are likely be a problems as well. As to "Do we have..": For we=Sun Microsystems, the Sun Ray group has PAM stacks that don't require user input and PAM modules that should run before the screen unlock dialog is shown (or at least before it is finished by the user). We just had to give up porting a working architecture for a Solaris+xscreensaver/dtsession context to Linux+gnome-screensaver and invent a completely different design (that isn't functionally equivalent). Even though Sun Ray is external to OpenSolaris, like an ISV, it demonstrates existence of such PAM stacks in real products or deployments. - J?rg Barfurth -- Joerg Barfurth Phone: +49 40 23646662 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
