Pam_selinux behavior incorrect?

[mike at flyn.org]

>>> 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.

Here is another possible solution: 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!

Just another suggestion.

--
Mike