[cap-talk] Confinement Confusion, MLS and POLA
Jed at Webstart
donnelley1 at webstart.com
Tue Jul 18 14:34:08 EDT 2006
At 08:47 AM 7/18/2006, Karp, Alan H wrote:
>David Hopwood wrote:
> >
> > But I never really understood why the simple security property or the
> > *-property would be desirable anyway, given the restrictions
> > they place
> > on frequently needed patterns of cooperation. It is very odd that
> > these properties have been considered important challenge problems for
> > access control systems, when they are almost irrelevant to real-world
> > security problems, and rigorous enforcement of them would often
> > *preclude* secure cooperation.
> >
>The Bell-LaPadula model also includes a means for explicitly lowering
>the security level. Hence, a High object can create a High message
>"Tell me when you see an enemy soldier.", have it declassified and
>transmitted it to Low objects.
Right. The above sort of mechanism (which I agree is needed for almost
any practical purpose) seems to me to make clear the nonsense
of this whole effort. The MLS mechanism is supposed to be "mandatory".
That is, the subjects involved have no control. However, if you allow the
above then it seems to me a clear violation of the * property (disallow
write down).
>Each Low object makes its reports as
>High. Hence, only Highs can aggregate the data, but Lows know what data
>to send.
Write up is allowed.
>You can turn this example around. The Low writes to High a message
>"Where should I go?" High uses the aggregated information on enemy
>locations sent by the Lows, creates a response as High, has it
>declassified and sent to Low. Awkward but useful.
And in clear violation of the * property (disallow write down).
>I believe this approach is used in real life (death) situations that
>don't involve computers at all. Indeed, as has been noted on this list,
>the sense is "We trust the people; they've been cleared.
Which is itself of course nonsense and seems to have been realized
in recent years. The whole MLS security mechanism in fact makes it
more easily abused by cleared but untrustworthy people, e.g. see the
discussion of the John Walker spy case:
http://www.eros-os.org/pipermail/cap-talk/2005-November/004366.html
and
http://www.fas.org/irp/eprint/heath.pdf
(very interesting reading, particularly for anybody who believes in the
value of MLS).
>It's the
>computers we're not sure of." If only a person can declassify the data,
>the inability of a High process to talk to Low makes sense while not
>precluding the desired collaboration.
Even with people only authorized declassifiers are given the permission
to declassify data (in my experience at LLNL and in DOD). That's why
it's called "mandatory" access control.
The MLS scheme was designed to work with people. It was used with
some success for many, many years in the military. They tried to apply
it to computer systems (processes acting on behalf of people - ambient
authority and all that) and it started to break down. When it came to
interprocess communication systems (networks) it breaks down altogether
as it implies that there can be no request/reply communication between
the levels, making networking essentially impossible in a multi level system.
As far as I know it's pretty much been abandoned now except for academic
exercises - thought I'd be quite interested to hear of ongoing
practical applications,
particularly in multilevel network communication systems (as we had between
about 1969 and 1995 at LLNL). Some rather ad hoc work arounds can be
done in such a situation (which I would think would be common with MLS
systems these days as networks abound), but I'd be quite interested to
hear about the sorts of work arounds that others use.
Of course communication about such systems is also hampered, which
again makes abuses like the Walker spy case more likely. Bad situation
in my opinion. Fortunately not functionally related to the POLA value of
capability systems (referred to as "need to know" in the MLS world) which
is a positive value and eminently achievable even in network systems.
--Jed http://www.webstart.com/jed/
More information about the cap-talk
mailing list