>> 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. -- Mike :wq
