[redhat-lspp] Getting rid of multilevel objects

[Casey Schaufler]

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

> On Fri, Jul 07, 2006 at 03:03:52PM -0700, Casey
> Schaufler wrote:
> > --- Klaus Weidner <klaus at atsec.com> wrote:
> > 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
> 
> People are working on this, but I'm not aware of
> current plans to include
> that in an evaluated configuration.

It's always the first thing to go.

> I think the main expectation is that
> it works for ssh sessions in combination with
> labeled networking.

If Fred logs in at Secret, and the device
(be it a vt100, pty, or something else) gets
labeled Secret (as it ought) there is no
safe way for newrole (or any command) to
switch MLS labels for the session. If the
label of the device is unchanged the
resulting session can't write to it. If
the label of the device is changed then
the "other end" of the connection can't
write to it. This is especially true of
labeled network connections, where the
"other end" is spitting labeled packets.

> > - 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.
> 
> That's obviously safer, but incompatible with having
> newrole be the only way to choose a level.

Yes, it's incompatible. If I knew a way that
would be and that would meet B1/LSPP requirements
I'd have done it for my 1995 and 2002 evaluations.
I could be wrong, but I don't think you'll
have much choice against the requirements.


> > - Required logout/login to change MLS label. 
> 
> ... which isn't currently supported.

Best get to work on it then.

> > > 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.
> 
> SELinux does this, read/write fail on open file
> descriptors if the
> underlying permissions change.
> 
> > Of course, that puts you into a situation
> > that's indistinguishable from having closed
> > the descriptors.
> 
> Not quite, trusted programs ...

Are decidedly uninteresting.

> could have an override
> capability which lets
> them communicate anyway while still keeping that
> functionality away from
> ordinary users. The challenge is doing that cleanly
> and safely in sshd
> in combination with labeled networking...

I claim that you can't do it and maintain
the integrity of your MLS.


Casey Schaufler
casey at schaufler-ca.com