Bug 121650

Summary: su's interaction with pam_selinux incorrect
Product: [Fedora] Fedora Reporter: W. Michael Petullo <redhat>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dwalsh, nalin, sds
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-07-22 19:08:18 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description W. Michael Petullo 2004-04-24 11:27:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6)
Gecko/20040312 Epiphany/1.1.12

Description of problem:
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.

Version-Release number of selected component (if applicable):
coreutils-5.2.1-3

How reproducible:
Always

Steps to Reproduce:
Use su to become another user and then log out.  Notice the security
context of any PAM modules are run by pam_close_session.  If
pam_selinux is removed from /etc/pam.d/su then the security contexts
of any PAM modules are run by pam_close_session are appropriate.
    

Expected Results:  When pam_close_session is called, modules should
execute with the same SELinux security context as the parent su
process.  This matches how the standard Unix uid is handled
(change_identity() is called after fork).

Additional info:
Comment 1 Tim Waugh 2004-04-30 08:56:00 EDT
CCing SELinux and pam expertise..
Comment 2 Stephen Smalley 2004-05-13 12:15:02 EDT
pam_selinux sets the exec context upon pam_open_session, which only
affects subsequent execution of programs (e.g. the user shell) and
does not affect the current context of the running process (e.g. login
or su).  It also resets the exec context to its original value upon
pam_close_session.  So I think that this is only a problem for helper
programs run by pam modules in the stack _after_ pam_selinux upon a
pam_open_session and _before_ pam_selinux upon a pam_close_session.

Can we address this issue by altering the placement of pam_selinux in
/etc/pam.d/{login,sshd,su,gdmsetup}?

If not, then it seems like we need to directly patch the programs in
question (login, sshd, su, gdmsetup).
Comment 3 W. Michael Petullo 2004-05-13 12:45:27 EDT
I will take a closer look at this order-related interaction as soon as
I get the opportunity.
Comment 4 W. Michael Petullo 2004-05-14 12:06:22 EDT
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.

Another possible solution is to 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!

At first I really liked the idea of doing this SELinux magic with PAM,
but now I am not so sure.  It seems like things may just get too ugly.
 In addition, as Stephen pointed out, the traditional Unix UID changes
are not done using PAM.
Comment 5 Daniel Walsh 2004-05-14 15:53:28 EDT
The only change is on an execed application, not on the context of the
running application.  IE pam_selinux causes the all future execed
applications to run as user_t for example instead of user_su_t which
is what the su command is running as.  So the only problem that I
would run into would be if pam_foo did a fork/exec in its open_session
(If it came after pam_selinux) or in its pam_close_session (If it was
called before pam_selinux close session.)  So in theory this is a
problem, and can be mitigated somewhat by moving the pam_selinux to
the bottom of the pam_sessions list.  I think it is somewhat unlikely
that people are doing fork/exec in their pam sessions.
Comment 6 W. Michael Petullo 2004-05-14 17:36:03 EDT
My pam_mount module does a fork/exec to execute smbmount, ncpmount,
etc. and umount.  Pam_mount will not work right with pam_selinux in
its current form.  I don't think that the problem can be mitigated by
moving pam_selinux to the bottom of the PAM sessions list (see
Catch-22 in comment #4).  Am I missing something?
Comment 7 W. Michael Petullo 2004-07-22 19:08:18 EDT
This seems to be fixed in new versions of Red Hat's PAM package (I'm
using pam-0.77-49).  Pam_selinux now takes open and close arguments,
forcing the module to run on pam_session_open or close only:

session    required     /lib/security/$ISA/pam_selinux.so close
session    required     /lib/security/$ISA/pam_stack.so
service=system-auth
session    required     /lib/security/$ISA/pam_selinux.so open multiple

This isn't a beautiful solution, but its pretty clever given the
constraints of the current PAM system.