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

Bill Tulloh btulloh at gmail.com
Thu Nov 16 05:11:13 CST 2006


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

> >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;
>
> I've never understood that performance issue.  I see no reason for
> capability systems to perform any worse than identity based systems.

I'm not sure how much of this early concern was based on perception
rather than reality, but you do see performance brought up as an issue
now and again. For example, you see people like Roger Needham
complaining about performance of CAP, attributing it not to
capabilities, but to certain design decisions. I think from the
outside some of these fine distinctions were lost; people just
understood CAP = slow.

> >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.
>
> Did it?  What were those problems?  Were they any more than
> not Unix/Windows?  It appears to me that KeyKOS ran into the
> same problem - namely lack of compatibility with the emerging
> market leading paradigm.  I'd be interested to hear how you see
> things differently.

The problem I had in mind was that KeyKOS avoided the fate of becoming
a large, expensive, failed corporate development effort like those at
IBM and Intel. KeyKOS may have later failed the market test, but it
did manage to make it to market and have some customers. Again, I
worry about guilt by association; even if capabilities weren't the
cause of the failure of Future Systems and Intel 432, being associated
with billion dollar corporate failures, couldn't have been good for
investor confidence.

> >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.
>
> Failure of "timesharing"?  I'm afraid I'm still not following you.
> All modern systems are "timesharing" systems.  There's no
> failure there that I see.

I meant the failure of the time-sharing industry, leading to the
demise of companies like Tymshare. The original design goal was to
support the business model of Tymshare. By 1984 when McDonald-Douglas
purchased Tymshare, this model appears to have been mostly dead.
KeyLogic (and here my knowledge is limited) appears to have sought
other markets for KeyKOS based on transaction processing, and
multi-level security, but ultimately without financial success. EROS,
of course, later demonstrated that the KeyKOS architecture could be
brought to the world of personal computers.

> The problem with the above (Lampson and Schneider) I believe is ignorance.
> Neither have ever seen an object/capability paradigm through to a complete
> system.  They imagine POLA implemented by third party administrators
> that must manage ACLs to the least privilege principle.  They imagine
> something along the lines of administratively controlled Mandatory Access
> Control as per the MLS schemes that have worked out so disastrously
> in the military (about that we agree).
>
> What I believe they don't understand and/or fail to appreciate is that
> POLA implemented with object/capabilities is almost entirely just
> good object programming - parameter passing rather than using
> "global" state sharing (authenticated through identities).

There does seem to be an assumption that POLA requires fine-grained
micro-management. From a global, third-party perspective, I guess it
does. This is where I see CapDesk and Ping's work as being so
important to show that such doesn't need to be the case.

> Lampson certainly refers to and suggests using delegation extensively,
> e.g. when he discusses the "speaks for" relation (e.g. page 15 of the
> charts:  http://www.usenix.org/events/sec05/tech/lampson.pdf ).

While I'm not too familiar with it, the approach Lampson and his
colleagues are taking does seem to be concerned with extending the
identity-based approach to deal both with distributed identities and
with processes having their own identities. This distributed identity
approach perhaps needs more attention from those advocating a
distributed capabilities approach.

> This is all fine to attempt to add mutual suspicion between people
> and programs and/or between cooperating processes to systems.
> However, I think the "rub" is that most computer security are
> unwilling to sacrifice the ability to know and manage who has
> access to what for that additional facility (see my following message
> on "...the rub, an account" for more details.

My concern is that without POLA, this knowledge and control that
people are unwilling to sacrifice appears to be an illusion. It is
what Friedrich Hayek would call a pretense of knowledge. You are
forced into making simplifying assumptions to deal with the
complexity, such as running all code with user authority, or assuming
that controlling permission is the same as controlling authority.
These assumptions may leave you the illusion of control, but they
don't accurately capture what is really going on.

> >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.
>
> Hmmm.   I don't follow you there.  The ACL people (e.g. the NCSC TCSEC
> folks) also blithely suggest that "principles" can be processes and you
> can still manage the "access matrix" with ACLs.  This is where I think
> Lampson is quite right.  Such a pursuit is impossibly complex and
> doesn't get the right information to the mechanisms with policy that
> need to manage such access control.

I was merely alluding to the notion that from a object-capability base
you create "access abstractions" and "patterns of secure cooperation"
that meet a variety of different policy goals, e.g. KeySAFE was built
on top of an object-capability foundation to address MLS concerns. I'm
skeptical of the ability of identity-based systems to successfully
reach down to the process level and below for complexity reasons.

> This is one of what I consider to be the beauties of capabilities.  Namely
> that they work on the intuitive and obvious object model where it's just
> parameters (objects) that need to be communicated in any case, so
> bundling a permission with the object designation makes perfect
> sense.

Exactly.

> > > 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 is getting
> >stronger little by little.
>
> That's not my sense of things.  I'm of course involved in much of the cap-talk
> discussion, but to me that's just incrementally approaching some sort of
> asymptote that's much below the level of shaking, convincing, selling those
> who need to be shaken, convinced, sold on the object/capability model
> as a viable one that's worth investing in before it will become a serious
> contender for market share - even with something as tenuous as the Hurd.

Perhaps, but considering where things were ten years ago where only a
handful of people were interested in capability-based approaches, I
think there has been some impressive achievements. This may still be
below what's needed for a major commercial breakthrough, but little by
little. I've always thought the sweet spot for capabilities was to
show the object-oriented folk what a natural fit it is, not to try to
convince the old computer security guard that the approach they have
been pursuing is a dead-end. The control mindset is difficult to
overcome.

Bill


More information about the cap-talk mailing list