Bug 200110 - LSPP: MLS policy not properly enforced on pseudoterminals (pty)
LSPP: MLS policy not properly enforced on pseudoterminals (pty)
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: policycoreutils (Show other bugs)
All Linux
urgent Severity medium
: ---
: ---
Assigned To: James Antill
Brian Brock
: Reopened
Depends On: 213810 213811
  Show dependency treegraph
Reported: 2006-07-25 11:08 EDT by IBM Bug Proxy
Modified: 2007-11-30 17:07 EST (History)
11 users (show)

See Also:
Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-07 19:09:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
exploit program (402 bytes, text/plain)
2006-07-25 11:11 EDT, IBM Bug Proxy
no flags Details

  None (edit)
Description IBM Bug Proxy 2006-07-25 11:08:20 EDT
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

    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

[kw@rhel5lspp ~]$ python newrole_typescript.py -l s2-s2 -- -c "ls -lZ
secret_file.txt; cat secret_file.txt"
Authenticating kw.
-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

Comment 1 IBM Bug Proxy 2006-07-25 11:11:25 EDT
Created attachment 132994 [details]
exploit program

exploit programthe exploit program referenced in the original description
Comment 4 Jay Turner 2006-09-29 11:58:50 EDT
Beta blocking according to section 14b of the release criteria.
Comment 6 Eric Paris 2006-10-04 11:45:22 EDT
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...
Comment 7 Klaus Weidner 2006-10-04 18:46:01 EDT
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

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.
Comment 8 Klaus Weidner 2006-10-05 12:22:12 EDT
See also the "newrole - adding capabilities for polyinstantiation" discussion on
the selinux mailing list:
Comment 12 Steve Grubb 2006-12-01 14:46:25 EST
This problem was fixed on bz #213812. The final solution was enhancement to

*** This bug has been marked as a duplicate of 213812 ***
Comment 13 Klaus Weidner 2007-01-03 16:59:42 EST
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.
Comment 14 Linda Knippers 2007-01-03 17:08:07 EST
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.  
Comment 15 James Antill 2007-01-04 11:05:20 EST
 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.
Comment 16 Pete Graner 2007-01-04 12:02:41 EST
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.
Comment 17 Steve Grubb 2007-01-04 14:20:44 EST
What about making the -l and -c command line options conflict? Meaning the
program errors out if they are both given.
Comment 18 Linda Knippers 2007-01-04 15:05:01 EST
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 19 Linda Knippers 2007-01-04 18:32:46 EST
Comment 15 said I'm looking at newrole changes, and I did that, but Dan
has posted a patch for review.
Comment 20 Klaus Weidner 2007-01-04 20:02:14 EST
FYI, patch and discussion are on the redhat-lspp mailing list:


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.
Comment 21 Daniel Walsh 2007-01-05 15:50:16 EST
Added patch in 
Comment 22 RHEL Product and Program Management 2007-02-07 19:09:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.