[redhat-lspp] Getting rid of multilevel objects

[Casey Schaufler]

--- LC Bruzenak <lenny at bruzenak.com> wrote:

> Add it in post-evaluation and the accreditors balk.

As, of course, they ought.

> > I claim that you can't do it and maintain
> > the integrity of your MLS.
> 
> Casey, can you elaborate a bit on this assertion?
> I agree it is not without risk but feel it may be
> acceptable given that
> the trusted program should be well-behaved. Or does
> it open an exploit
> potential?

Let's follow the flow of events. Barney logs
onto the system over a labeled network connection.
Some mechanism is used to determine what MLS
label the session should have: CIPSO, IPSEC,
Barney's clearance, and the address of remote
host are all mechanisms that can work. Barney's
shell will get the label chosen and all resources
dedicated to the session, such as a pty, will get
that label. Barney, being an unprivileged,
untrusted, "normal" user then performs some
arbitrary actions that may include accessing
and/or opening objects at his label. Further,
the system will communicate with the remote
host, providing information that the other
end of the connection is know allowed to see
because of the integrity of the aforementioned
label establishment mechanism.

Let us assume that a mechanism exists for Barney
to change the MLS label of his session, and for
convinience let's call it newrole. Barney uses
newrole to change his MLS label to one that is
dominated by, but not equal to, the label with
which he logged into the system. Policy has been
violated, since he could now create a file and
fill it with higher labeled information gathered
prior to the newrole invocation. Next, Barney
uses newrole to change his MLS label to one that
dominates, but is not equal to, the label with
which he logged into the system. For grins,
let's say that his shell has reopened stderr
to a file for logging purposes. The newrole
utility passes open file descriptors along,
so now Barney can read higher labeled
objects and pass the information downward by
writing it to stderr.

The labeled network mechanism won't allow
the relabeled process to communicate over
the labeled socket in any case because doing
so would violate the MLS enforcement on the
socket. Even if newrole does provide either
of these strictly illegal facilities you still
have the problem of communicating with the
remote host. An implementation must not allow
a process to inaccurately associate the MLS
label of the data transmitted over a socket.

The newrole program can behave safely, or it
can provide convinience, but it can not do both.
Changing a session MLS label in an environment
that preserves existing state is not going to
work because of the existing state.

A newrole program that destroys the old session
and creates a new, clean session with the new
MLS label is a better choice, although you still
have the problems associated with communicating
with the remote host.



Casey Schaufler
casey at schaufler-ca.com