>>> I am very interested in hearing opinions/input on the following bug: >>> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121650 >>> >>> To summarize: >>> >>> The su command, included in the coreutils package, does not interact >>> with pam_selinux correctly. Su calls pam_open_session before forking >>> to create a user's shell. Since pam_selinux is executed before >>> forking, the SELinux domain of both the user's shell and the parent su >>> process are modified. The result of this is that any PAM modules that >>> are run by pam_close_session when the user logs out are executed with >>> the user's SELinux security context instead of su's (user_t vs. >>> user_su_t). >>> >>> The catch-22 is that if pam_open_session is called by the child after >>> the fork then the parent's pam_close_session with have no knowlege >>> that there is an open session. >>> >>> This all contradicts with how su treats traditional Unix UID handling. >>> Su changes its UIDs to the user after it forks so that the parent su >>> process continues to execute as root. The result of this is that, >>> when using the traditional Unix security model, modules executed by >>> pam_close_session have root privileges. I would argue that this is the >>> correct behavior. >>> >>> I think /bin/login is in the same boat. >> IIRC, on pam_open_session, pam_selinux sets the exec context for the >> process to the appropriate context for the user, so that any >> subsequently executed programs will transition into that context. On >> pam_close_session, pam_selinux restores the exec context to its original >> value, so any subsequently executed programs will revert to the prior >> behavior. The principal concern seems to be the impact on helper >> programs executed by other pam session modules invoked after pam_selinux >> when opening a session, and the impact on helper programs executed by >> other pam session modules invoked before pam_selinux when closing a >> session, as any such helper programs will end up in the user's context. > Here is the new dilemma: > > Imagine a module, call it pam_foo, that requires special privileges > to properly open and close a user's session. Currently, one has two > basic configuration options: > > session pam_foo ... > session pam_selinux ... > > or > > session pam_selinux ... > session pam_foo ... > > In the former, pam_foo will not have the needed privileges when the > session is to be closed (pam_selinux has not restored them yet). In the > latter, pam_foo will not have the privileges needed to open the session > (pam_selinux has already taken them away). > > One possible solution would be to modify PAM to invert the order in > which modules are executed by pam_close_session. This seems to make > sense conceptually but I am not sure if this would be a violation of > the PAM standard. > > At first I really liked the idea of doing this SELinux magic with PAM, > but now I am not so sure. As Stephen pointed out, the traditional Unix > UID changes are not done using PAM. Here is another possible solution: break pam_selinux into pam_selinux_open and pam_selinux_close. Pam_selinux_open provide pam_open_session functionality and pam_selinux_close would handle pam_close_session. This would allow one to do something like this: session pam_selinux_close ... session pam_foo ... session pam_selinux_open ... The problem is you basically must have written a module yourself to understand PAM enough for this to be intuitive! Just another suggestion. -- Mike
