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.
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.
I am out of my depth here -- does this still apply?
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.
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.
So if I understand correctly, pam_selinux can re-open the tty itself.
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.
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.
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.