Red Hat Bugzilla – Bug 200110
LSPP: MLS policy not properly enforced on pseudoterminals (pty)
Last modified: 2007-11-30 17:07:32 EST
LTC Owner is: kweidner@us.ibm.com LTC Originator is: kweidner@us.ibm.com Problem description: Multilevel security (MLS) restrictions are currently not properly enforces on pseudoterminal (pty) devices. It's simple for a user cleared for a range of labels to create a program that declassifies information without needing any special privileges. Hardware Environment Machine type (p650, x235, SF2, etc.): vmware Cpu type (Power4, Power5, IA-64, etc.): i686 Software: selinux-policy-mls-2.3.2-4, kernel-2.6.17-1.2293.2.8_FC6.lspp.44 How to reproduce: - running at the low level, create a pty master/slave pair. - on the slave end, spawn newrole to switch to a high level, send your password through the pty. - on the slave end, execute "cat secret_file". - as unprivileged process, read the secret data from the pty master end and write it to a low file. The attached program is an example, it's a wrapper for "newrole" with builtin "typescript" capability, which isn't supposed to work without having some type of override capability: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [kw@rhel5lspp ~]$ newrole -l s2-s2 -- -c "echo this is secret > secret_file.txt" [kw@rhel5lspp ~]$ id -Z staff_u:staff_r:staff_t:SystemLow-SystemHigh [kw@rhel5lspp ~]$ python newrole_typescript.py -l s2-s2 -- -c "ls -lZ secret_file.txt; cat secret_file.txt" Authenticating kw. Password: -rw-rw-r-- kw kw staff_u:object_r:staff_home_t:Secret secret_file.txt this is secret [kw@rhel5lspp ~]$ ls -lZ typescript.txt -rw-rw-r-- kw kw staff_u:object_r:staff_home_t:SystemLow typescript.txt [kw@rhel5lspp ~]$ cat typescript.txt -rw-rw-r-- kw kw staff_u:object_r:staff_home_t:Secret secret_file.txt this is secret ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Created attachment 132994 [details] exploit program exploit programthe exploit program referenced in the original description
Beta blocking according to section 14b of the release criteria.
So I'm not actually sure how to 'fix' this. If we were to enforce MLS 'no read up/no write down' from one end of a pty to the other it would be completely unusable. Actually that's not true, but you would have to have an MLS override in policy for whatever process was trying to use newrole, which seems like it would be a whole lot worse than we have now. If we were to relabel the master end of the pty it wouldn't be able to talk to the incoming network connection. So Stephen thought up the idea of only allowing newrole to work when the pty is created by a 'trusted' process. The thought is that ssh could be 'trusted' and a user shell would be 'untrusted.' The ptys are already initially labeled based on creator (e.g. sshd_devpts_t upon initial creation by sshd vs. user_devpts_t upon initial creation by user_t shell) and then relabeled based on type_change rules, so we could have them relabeled to e.g. sshd_user_devpts_t vs. just user_devpts_t, and then allow newrole to access the former but not the latter. It would be a fairly disruptive change to policy, but that is a lot easier than changing the kernel...
I think either of the options you mention would work: - allow master/slave ends to have different contexts, but enforce restrictions on the information flow and require MLS overrides for trusted processes - alternatively, always relabel both master and slave ends simultaneously to ensure that they always have the same context. Then, it's a feature (and expected) that the master end can't talk to the incoming network connection unless the process has a MLS override. I'm not convinced that the "trusted label" based approach would work. What about the following scenario: What happens when launching the ssh client on the slave end of a pty, logging in and using newrole, and then reading secret data on the pty master? The relabeling is being done by trusted programs. Something like this: [s0] exploit_program pty master <=> pty slave [s0] ssh localhost [s0] sshd trusted pty master <=> pty slave [s0->s1] newrole -l s1 [s1] cat secret_file Unless I'm misunderstanding it, you'll still get the secret data off the "s0" pty master in the exploit program.
See also the "newrole - adding capabilities for polyinstantiation" discussion on the selinux mailing list: http://marc.theaimsgroup.com/?l=selinux&m=116006455201016&w=2
This problem was fixed on bz #213812. The final solution was enhancement to pam_selinux. *** This bug has been marked as a duplicate of 213812 ***
The underlying issue in the pty handler is not fixed, the exploit program still works in current systems. The alleged duplicate bug #213812 is fairly different. The proposed workaround for the LSPP evaluated configuration is to restrict execution of the newrole program to root, and force non-root users to use the new PAM mechanism to select a level and role at login time instead of using newrole after login. This currently works for console login only, sshd does not support level selection (see RH bug #220487 for more about sshd). If this workaround is not acceptable please reopen the bug.
I don't like the proposed workaround, as I statedi n 213812. I think non-root users should still be able to run newrole to change roles and types and to use newrole to change level for non-interactive commands that don't require pty access. That was how Klaus described sane behavior in the mail thread referenced in comment #8 so perhaps that's what he really means in comment #12.
There was a discussion on IRC yesterday, I think that this was the outcome: You'd allow level change when run as root (or a different definition of privileged user), and when noninteractive (newrole doesn't do any tty relabel). In addition, level change would be ok if it can reliably relabel the entire tty (Ie. not just the slave end of a pty). Linda said she'd look at doing the newrole changes for that.
Unless we get a fix for this this week, I'm going to have to nack this for 5.0 and address it in a errata or 5.1, pls advise on the ETA of a fix.
What about making the -l and -c command line options conflict? Meaning the program errors out if they are both given.
This has been said on irc but I thought I'd update the bz. The issue isn't with -l and -c in combination, its with -l and a pty. Disallowing -l when the tty is a pty should be fine.
Comment 15 said I'm looking at newrole changes, and I did that, but Dan has posted a patch for review.
FYI, patch and discussion are on the redhat-lspp mailing list: https://www.redhat.com/archives/redhat-lspp/2007-January/msg00004.html I agree that this approach (don't permit newrole to use a pty if -l flag supplied) would fix the problem without the drastic step of restricting newrole to root use only.
Added patch in policycoreutils-1.33.8-2 libselinux-1.33.3-2.fc7 selinux-policy-2.4.6-23
A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.