[cap-talk] MLS gone bad - now capabilities? (was: NCSC TCSEC) Lampson trashes POLP
Jed at Webstart
donnelley1 at webstart.com
Wed Nov 15 19:33:26 CST 2006
At 03:08 AM 11/10/2006, Bill Tulloh wrote:
>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
Again we agree.
>Given the money and mind share behind the government's effort,
>this couldn't help but have a dampening effect on investment in
>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
I've never understood that performance issue. I see no reason for
capability systems to perform any worse than identity based systems.
>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.
The above are all fine, though I think perhaps there was just as much
of a demand for "security" back then - perhaps of a different sort. E.g.
there wasn't so much concern about viruses in those days.
From my perspective
>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
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
>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
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.
> > Sure, everybody agrees that POLA would be nice/helpful,
>I'm not so sure about this. Butler Lampson doesn't think so.
I certainly agree that Butler Lampson is the worse thing that every
happened to the object/capability paradigm. His name got associated
with capabilities early on regarding the CalTSS system (never put
into production, never even really worked through) and somehow he
became regarded as an expert on the subject.
From my perspective his writing in recent years has been pretty much
conservative apple pie and motherhood sorts of stuff arguing that what
we have has worked well enough and will continue to do so with perhaps
just a bit more diligence (not surprising for somebody working for
Microsoft I guess). For example, in the talk at the above he says:
"The danger is small, so it's OK to buy features instead of security.
Security is expensive. Security is a pain."
However, more particularly to our capability/POLA cause is this quote:
from Butler Lampson:
"I think, for example, that the Principle Of Least Privilege has done an
enormous amount of damage to security because what it encourages
you to do is to make everything fine grain and work out all the
dependencies very carefully and it's too complicated. You can't keep
track of it. You're bound to mess it up. Even if you get it right today
it will be wrong three months from now. Nobody will have the patience
to ever look at it again because there's just too much of it. So I say
absolutely no to fine grain protection. Everything should be as course
grain as possible because otherwise you won't be able to administer it.
That's a very unpopular position with most people. I think there's a lot
of empirical evidence that tells us now that it's right."
I believe Fred Schneider's concerns (below) are similar:
>and Fred Schneider argues that while it might be useful as an abstract
>goal, it is not implementable.
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).
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 ).
If well respected people like Lampson are giving talks, writing, etc.
and saying, "I say absolutely no to fine grain protection. Everything
should be as course grain as possible" then what hope is there for
advancement along the POLA lines? Wait for Lampson to retire into
obscurity, confront him and any who think like he does directly, or
try to work around naysayers like Lampson.
Generally I prefer direct confrontation and clearing the air.
> > 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
>"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
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.
>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.
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.
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
However, going from such a base and arguing that you should build
ACL or "ACL-like" systems on top of a capability base goes beyond
what I'm able to follow/appreciate/support at this time. I don't understand
how such a mechanism would work, though perhaps the discussion
in the "..., an account" message might move us in that direction.
>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.
I think that's right. Not just how one would go about doing it, but
actually doing it - a demonstration at least. Even with all the
object/capability systems that have been developed I don't know
of any that I believe measure up to the standard of such a
demonstration (again see the ", an account" message).
> > 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.
I'll pick up this thread in the ", an account" message.
More information about the cap-talk