Pam_selinux behavior incorrect?

[Stephen Smalley]

On Wed, 2004-05-12 at 18:04, W. Michael Petullo wrote:
> 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.

Note that we originally directly patched programs like login and sshd
for SELinux, but migrated to pam_selinux when Dan created it as a less
invasive alternative.  But perhaps there is a fundamental mismatch
between the PAM interface and our desired functionality?  We've raised
that issue in the past, as pam is not presently used to set uids, but it
seems unfortunate to have to patch every such program for SELinux.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency