Re: [redhat-lspp] Getting rid of multilevel objects

[Casey Schaufler <casey schaufler-ca com>]

--- Klaus Weidner <klaus atsec com> wrote:

> > The problem here is not with the pty, rather with
> newrole, which
> > oughtn't keep descriptors open if it is changing
> MLS label.
> 
> In this case, the descriptor is the standard input
> and output stream that
> newrole uses for interaction, including reading its
> password, and closing
> that will make it stop working

That is correct. In the context of MLS the
newrole command is flawwed in that it provides
a mechanism that allows the downward flow of
information.

> since the system
> doesn't have a trusted
> input/output path (which is a separate problem).

> newrole can't tell the
> difference between a legitimate pty use from ssh or
> in an xterm versus
> the unauthorized use, and it would be a very
> significant restriction to
> permit only console access for newrole use.

You're right. The MLS requirements make
this hard. You cannot change the MLS label
of a user session while leaving any of the
old accesses available. In the Unix world
this was addressed in a number of ways:

- MLS X11 servers
- Commands (e.g. newlabel or "su -M") that
  run a requested command at a higher MLS
  label but that close all open descriptors
  and reopen them on /dev/null.
- Required logout/login to change MLS label. 

> Would it work to have newrole relabel the pty (maybe
> in a PAM session
> module?), so that the controlling low process won't
> be able to read from it?

Hee Hee. This only works if you do the MLS
check on every fd operation. UNICOS/MLS did
this. You can do it in the pty driver, too,
if you only care about ptys. You could do it
in the driver for /dev/tty if you're ambitious.
Of course, that puts you into a situation
that's indistinguishable from having closed
the descriptors.


Casey Schaufler
casey schaufler-ca com