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
selinux@lists.fedoraproject.org