> 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