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