Bug 121650
Summary: | su's interaction with pam_selinux incorrect | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | W. Michael Petullo <redhat> |
Component: | coreutils | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | dwalsh, nalin, sdsmall |
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 23:08:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
W. Michael Petullo
2004-04-24 15:27:43 UTC
CCing SELinux and pam expertise.. 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). I will take a closer look at this order-related interaction as soon as I get the opportunity. 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. 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. 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? 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. |