[cap-talk] MLS gone bad - now capabilities? (was: NCSC TCSEC)

Bill Tulloh btulloh at gmail.com
Fri Nov 10 05:08:31 CST 2006


On 11/9/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> At 05:01 AM 11/5/2006, Bill Tulloh wrote:

> >It seems to me that part of what it did was distract R&D away from
> >capability-based systems.
>
> I don't believe that even now if one discounts MLS there is any
> "market" for object/capability systems.

I think these are separate questions. When TCSEC was getting off the
ground in the late seventies/early 1980s, capability-based systems
were still a viable alternative. The criteria laid out in the orange
book said identity-based systems are the gold standard (essentially
Multics + Bell La Padula) then held capability-based systems up to
that standard and found them wanting - surprise, surprise. Part of the
problem, I think, is that the early standard mixed mechanism
(identity-based) and policy (MLS); the unfortunate distinction between
mandatory (MLS) and discretionary policy (ACLs) is a good
example.Given the money and mind share behind the government's effort,
this couldn't help but have a dampening effect on investment in
capability-based systems.

I should be clear that I'm not trying to say that capability-based
systems had all the answers, or that all of the TCSEC effort was a
total waste. People were sill figuring out how to design
capability-based systems in useful ways, and no doubt the research
efforts spurred by TCSEC produced many useful ideas (It is pretty
clear however that the TCSEC efforts failed on its own terms of
seeding an active commercial market in trusted systems) I do think,
however, that there was a clash of paradigms that worked to the
disadvantage of capability-based systems.

The trusted system criteria clearly wasn't the only factor leading to
a move away from capability-based systems, nor do I think it was the
dominant one. Many of the capability-based projects of this time were
running into trouble of various sorts, performance issues being a big
one; and capabilities became associated with several big commercial
failures -- IBM Future Systems, and later Intel's iAPX 432. All of
this would help dampen investment. Also, it is far from clear how much
demand for security there really was back then.

This is why GNOSIS/KeyKOS intrigues me. It was a commercially funded
investment in a secure operating system, exactly the sort of thing
that the TCSEC was supposed to encourage, but failed to deliver.
Clearly at the time, Tymshare thought this was an investment worth
making. KeyKOS also provided an existence proof that contradicted many
of the concerns about capability-based systems, like poor performance
and the need for specialized hardware. It also appears to have avoided
the problems that plagued the large capability-based projects at IBM
and Intel. What seems to have done KeyKOS in was not problems with the
capability-approach but the failure of time-sharing. A reliable and
secure timesharing OS wasn't what the emerging world of PCs and
networks needed.

> Sure, everybody agrees that POLA would be nice/helpful,

I'm not so sure about this.  Butler Lampson doesn't think so.
http://www.usenix.org/events/sec05/tech/

and Fred Schneider argues that while it might be useful as an abstract
goal, it is not implementable.
http://www.cs.cornell.edu/fbs/publications/leastPrivNeedham.pdf


> BUT (and its a big BUT):
> 1.  How do you manage access control in an object/capability
> system (see my recent "Capabilities - the rub" message) -
> audit, remove, see, etc. and

I'm probably the least competent person on this list to tell you how
to build such a system, but I do think your "rub" is on to something.
Identity-based systems are modeled after people "owning" computational
objects, like files. The focus is on user as principal. This is a
legitimate pattern that ACL systems attempt to address.

What I take as the capability response to this, mainly from reading
this list, is two things.

1. Programs are people too.

Systems that base access control decisions on the identity of the user
only give you the illusion of control, because they make the
unwarranted assumption that the executing code faithfully pursues the
user's interest. Capability-based systems model programs as pursuing
their own separate interests, programs as principals. To quote Norm
Hardy:

"The idea of principal being important seems to assume that all of the
programs are doing just exactly what the initiator (principal?) wants
them to do. When the intentions of the various programmers are
considered, these security arguments dissolve in a mist. When I run a
program, it does what the author wants, subject only to the authority
that I have managed to limit it to. If the program author is
competent, ethical and we understand each other, it does what I want
too." http://www.cap-lore.com/CapTheory/Principal.html

Similarly, the distinction between authority and permissions depends
on recognizing the intentions of code.

2. Object-capabilities are foundational

I've always understood the message from this list as not arguing
against ACL-like systems, but as arguing that you should build them on
top of a capability-base, otherwise you can't solve number 1. You can
solve user-level access issues on top of a system that addresses
code-level access issues (POLA), but not the other way around.
Perhaps, what you are saying, is that we need to do a better job of
showing how one would go about doing this.

>
> 2.  Can you implement a capability system that's practical and
> get it marketed?  (standards for capabilities, interoperability,
> etc., etc.).
>
> I believe these are not light issues.  If the object/capability
> paradigm had a strong and together case for delivering
> on the above (which I argue it doesn't) then I think it would
> be a legitimate contender for at least research dollars.

This is something of a chicken and egg problem; research dollars could
be used to help one make the case. In the meantime, the incremental
approach will have to suffice. My own sense is that the case getting
stronger little by little.

Bill


More information about the cap-talk mailing list