MLS Challenge Problem

[shapj@us.ibm.com]

Here is the first of two challenge problems.  This one (I think) has a
solution.

Imagine that we are building a system that must satisfy the MLS policy.
That is, a system in which there are security levels (public, secret,
top-secret) and categories (red, green, blue).  To have access to something
a program must be in at least the required secrecy level and must be a
member of the appropriate categories.

Now consider the action of a program that manipulates a "file" which
contains both data and capabilities.  Imagine that the file is secret, and
that the program operates with the appropriate access rights to read and
write the file.  Among other things, it stores into the capability area of
the file a capability conveying write authority to some object.

At some later time, a different instance of the same program is started
within a top-secret compartment.  This program may read the file, and may
READ the object pointed to by the write-authorizing capability, but may not
write to that object because the object is at a lower secrecy level.

We do not wish to replicate the structure of the file.

Weak (sensory) capabilities is an inadequate solution, as the file
implementation is provided by a process.

For purposes of this challenge, you may assume that certain object types
are trusted (e.g. the file implementation might be accomplished by trusted
code) and that the reference monitor has means to determine whether the
object named by a capability has a trusted implementation.

Design an efficient implementation by which these restrictions can be
successfully imposed.  In particular, address the question of how the
trusted file implementation is able to determine the security attributes of
its invoker, or by what means this determination is rendered unnecessary by
the reference monitor.


Jonathan S. Shapiro, Ph. D.
Research Staff Member
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 7595