Bug 132914

Summary:	su should re-open terminal for correct SE Linux functionality with strict policy
Product:	[Fedora] Fedora	Reporter:	Russell Coker <russell>
Component:	pam	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	dwalsh, sdsmall, tmraz, twaugh
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:	2005-09-09 21:20:42 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:
Bug Depends On:
Bug Blocks:	131774

Description Russell Coker 2004-09-19 14:53:50 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)

Description of problem:
Newrole will re-open the tty device, while su has similar functionality to newrole but does not re-open the tty.

This means that running "newrole -r sysadm_r" before running "su -" gives a terminal file handle labelled as sysadm_t while just running "su -" gives you a sysadm_t domain for the process but still keeps the staff_t label on the file handle.

The result of this is that some programs which are normally run from sysadm_t will fail because they have not been permitted to use the staff_t file handles, and also when doing "su - user" from sysadm_r the su operation will fail entirely as the shell is not permitted to use file handles 0, 1, and 2.

The solution to that is that su should close file handles 0, 1, and 2 (ideally close all file handles) and then re-open the terminal before dropping privs to execute the user process.

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


How reproducible:
Always

Steps to Reproduce:
On a SE Linux machine with strict policy run "su -" and observe that programs such as "mailq" are not permitted to write to the terminal.

Additional info:

NB  This doesn't entirely solve the problem, we need a minor policy change too.  I'll do the policy change.

Also if you want administrative access to a Fedora machine to test this please email me.

Comment 1 Stephen Smalley 2004-10-04 15:24:16 UTC

IIRC, we used to have this functionality in pam_selinux, but it was
dropped as it did not interact well with su (attempt to re-open tty
would fail due to changing of fsuid/fsgid prior to invocation of pam
modules, or something like that) and we also had related issues with
sudo.  Need to go back and review prior email discussions and bugzilla
reports in this area.

Comment 2 Tim Waugh 2004-10-14 13:55:09 UTC

I am out of my depth here -- does this still apply?

Comment 3 Stephen Smalley 2004-10-14 14:26:01 UTC

su changes fsuid prior to calling pam_open_session, so that
pam_selinux cannot re-open the tty when su'ing to a non-root user.  I
have an email from Feb 2004 discussing this issue with Dan, Russell,
and Nalin.  Further, re-opening tty in pam_selinux was posing problems
elsewhere as well, e.g. sshd, although that is now obsoleted by the
use of a direct patch for sshd again.  Also seems inappropriate for login.

If we truly want su to re-open the tty, then I think we have to
directly patch it rather than using pam_selinux for it.  But it isn't
clear that doing this will alleviate the policy issue elsewhere;
consider other programs like sudo and userhelper, e.g. see bug 120213
and prior discussions/bugzillas on this issue.

In the past, this was addressed in the policy by adding 'privfd' to
the user domains (in the type declaration in full_user_role), so that
all programs can inherit the original descriptors.  It appears that
this has been removed from the policy in the recent past.  I don't
know why; patch was one merged by James from Dan.

Comment 4 Tomas Mraz 2005-09-09 10:12:15 UTC

su from coreutils>=5.2.1-34 (FC4 already) doesn't set explicitly the fs uid. It
changes to the requested user only after the pam_open_session call.

Comment 5 Tim Waugh 2005-09-09 10:34:39 UTC

So if I understand correctly, pam_selinux can re-open the tty itself.

Comment 6 Tomas Mraz 2005-09-09 11:20:14 UTC

The question is what is the most correct way to fix this problem:

1. patch all su-like programs to reopen the tty
2. add reopening of tty to pam_selinux
3. 'privfd' in user domains

Someone (from selinux developers?) should decide which possibility is the best.

Comment 7 Stephen Smalley 2005-09-09 18:11:47 UTC

Option 3 is the current status; user domains have privfd in the strict policy.
targeted policy has no issue here as users are unconfined.

Option 2 could have side effects on login, which also uses pam_selinux and has
no reason to reset the fd, and doesn't address sudo or userhelper.

Re-opening the tty in su would help with the descriptor labeling problem, but
not with the issue of sharing a controlling tty.  I'm not sure what can be done
about that for an interactive su shell; for su -c and sudo, one might be able to
  use a proxy pty.  This is similar to the run_init utility and open_init_pty
helper handler for running init scripts; that is used by the Debian selinux folks.

Comment 8 Tomas Mraz 2005-09-09 21:20:42 UTC

So from Stephen's comment I concluded it isn't worth it to implement the
re-opening as it wouldn't resolve the sharing of a controlling tty anyway. If
someone disagrees please reopen this bug or open a new one with exact proposal
how to solve this problem.