From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6) Gecko/20040312 Epiphany/1.1.12 Description of problem: 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. Version-Release number of selected component (if applicable): coreutils-5.2.1-3 How reproducible: Always Steps to Reproduce: Use su to become another user and then log out. Notice the security context of any PAM modules are run by pam_close_session. If pam_selinux is removed from /etc/pam.d/su then the security contexts of any PAM modules are run by pam_close_session are appropriate. Expected Results: When pam_close_session is called, modules should execute with the same SELinux security context as the parent su process. This matches how the standard Unix uid is handled (change_identity() is called after fork). Additional info:
CCing SELinux and pam expertise..
pam_selinux sets the exec context upon pam_open_session, which only affects subsequent execution of programs (e.g. the user shell) and does not affect the current context of the running process (e.g. login or su). It also resets the exec context to its original value upon pam_close_session. So I think that this is only a problem for helper programs run by pam modules in the stack _after_ pam_selinux upon a pam_open_session and _before_ pam_selinux upon a pam_close_session. Can we address this issue by altering the placement of pam_selinux in /etc/pam.d/{login,sshd,su,gdmsetup}? If not, then it seems like we need to directly patch the programs in question (login, sshd, su, gdmsetup).
I will take a closer look at this order-related interaction as soon as I get the opportunity.
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. Another possible solution is to 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! At first I really liked the idea of doing this SELinux magic with PAM, but now I am not so sure. It seems like things may just get too ugly. In addition, as Stephen pointed out, the traditional Unix UID changes are not done using PAM.
The only change is on an execed application, not on the context of the running application. IE pam_selinux causes the all future execed applications to run as user_t for example instead of user_su_t which is what the su command is running as. So the only problem that I would run into would be if pam_foo did a fork/exec in its open_session (If it came after pam_selinux) or in its pam_close_session (If it was called before pam_selinux close session.) So in theory this is a problem, and can be mitigated somewhat by moving the pam_selinux to the bottom of the pam_sessions list. I think it is somewhat unlikely that people are doing fork/exec in their pam sessions.
My pam_mount module does a fork/exec to execute smbmount, ncpmount, etc. and umount. Pam_mount will not work right with pam_selinux in its current form. I don't think that the problem can be mitigated by moving pam_selinux to the bottom of the PAM sessions list (see Catch-22 in comment #4). Am I missing something?
This seems to be fixed in new versions of Red Hat's PAM package (I'm using pam-0.77-49). Pam_selinux now takes open and close arguments, forcing the module to run on pam_session_open or close only: session required /lib/security/$ISA/pam_selinux.so close session required /lib/security/$ISA/pam_stack.so service=system-auth session required /lib/security/$ISA/pam_selinux.so open multiple This isn't a beautiful solution, but its pretty clever given the constraints of the current PAM system.