Re: Pam_selinux behavior incorrect?
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(a)epoch.ncsc.mil>
National Security Agency