Downgrading labels

[Robert Watson]

On Sun, 27 Mar 2005, David Collier-Brown wrote:

> Robert Watson wrote:
> > If you set a subject label with high, effective, and low labels identical,
> > then there is no useful ability to relabel.  However, you can use this
> > mechanism to create daemons with limited privilege -- the ability to
> > relabel solely between a limited set of compartments or levels, for
> > example.  This is a bit more granular than a single "is privileged" bit,
> > and I think offers some useful benefits.
> 
>   Can you speak a bit on relabeling between compartments? I tend to use
> the term to indicate a level/category pair (eg, A & Q, secret)  and
> wonder if you are using the term the same way. 
>   If I had a document that was in the Admin and Quartermaster
> categories, at secret, and I had the appropriate privilege, could I
> relabel it just (Admin, secret)? 
>   I'm specifically thinking of a scenario in the commercial world,
> companies A and B work together on a project, and A takes the combined
> work and relabels it (A, top secret), while B relabels it (B, public
> domain). 

The TrustedBSD implementations of Biba and MLS have pretty much the
standard interpretations of levels and compartments.  In general, our
Biba/MLS labels consist of hierarchal and non-hierarchal (compartment)
components, where direct numeric comparisons are used for the hierarchal
component (level/grade) and set operations are used for the non-hierarchal
component in defining a dominance operator. 

Two system objects use a more complex notion of label: our subject label,
which combines three of the above (effective, range low, range high) to
create the complete process label, and network interface labels, which
have (default, range low, range high) for default labels on in-bound
packets, as well as constraints on the labels of data sent via the
interface.  All other objects (files, IPC objects, etc) have a simple
level+compartments without a range.

A typical use of a subject range might be as follows: the "high" label
might consist of "top secret + compartment A + compartment B", and the
"low" label in the range might consist of "secret".  The process can
change its effective label or an appropriately labeled object to any of
the following: 

   secret
   secret + A
   secret + B
   secret + A + B
   top secret
   top secret + A
   top secret + B
   top secret + A + B

So you can run a semi-privileged process to act as a trusted gateway
between the compartments, moving data between them, etc.  It doesn't have
full privilege in the context of MLS, since it can't arbitrarily relabel,
but it can act with privilege with respect to particular compartments or
ranges of levels.  If you assign both range endpoints to the same label as
the effective label, then this model degrades to more traditional MLS.

An example of the above "in use" might be following: two network
interfaces exist on the system, each labeled with a compartment
representing the company associated with the network segment.  Users log
into the system using these interfaces and use processes labeled with the
compartment associated with their company.  A trusted mail delivery
process is granted access to both compartments, and is able to change the
labels on queue files, limit itself to a single compartment, etc, for the
purposes of moving data between the companies.  If a third network
interface exists on the same machine, along with a third defined
compartment, the daemon would be unable to access files or network
interface associated with that compartment, since its range includes only
the former two compartments.  Likewise, it would be unable to relabel
files to the additional compartment by the rules defined above. 

Robert N M Watson


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message