[cap-talk] More Heresey: ACLs not inherently bad

[Marcus Brinkmann]

Hi,

At Wed, 24 Sep 2008 21:37:40 -0700 (PDT),
David Wagner <daw at cs.berkeley.edu> wrote:
> 
> Marcus Brinkmann writes:
> > Discussions on this mailing list have
> > shown how hard it is to define what it should mean to share a
> > capability with another principal (should it be revocable or not?
> > should capabilities fetched through the capability be revocable or
> > not?).  These semantic issues disappear in simpler systems.
> 
> I don't see why those issues disappear.  It seems to me that those
> issues are fundamental and every system has to take a position on the
> answers to those questions.  The simpler systems just take a single
> position, don't give users any other choice ("you can have any color
> you like, so long as it is black"), and accept any negative consequences.
> If you want to do that in an objcap system, you can pick a single
> position and support only that model -- you can do that if you want.
> So I don't quite understand this criticism.

Ok, fair enough.  But what you are saying implicitely is that "the"
capability systems doesn't exist, and I can't criticize what doesn't
exist.  If I take this seriously, Unix wins on all issues by absence
of competition.  And in a sense, this is actually the truth.

But capability researchers have a somewhat clear vision about their
favoured architecture for capability-based operating systems.  They
cite the same reference implementations (KeyKOS, etc) and core papers.
They highlight the same principles (POLA, security by designation,
...).  I think that a pattern emerges.  Once you get down to the
details, favoured choices for capability systems disappear, and the
remaining acceptable positions are surprisingly narrow.

I try to contrast Unix with the best capability system in the spirit
of the tradition of capability research that I can imagine.  That
picture is necessarily fuzzy, but it's the best I can do towards a
fair comparison.

> > To choose
> > a non-operating system example for collaboration, Wikipedia is
> > extremely successful, and its security model is very different from
> > capabilities, relying on recoverability and monitoring instead of
> > access control.
> 
> I certainly don't claim that objcaps solve all security problems --
> they clearly don't.  I think a more interesting question is, are they
> useful in a particular domain that has practical relevance?

That's ok, I didn't say that you or anybody else claims that.
However, some people on this list have repeatedly voiced their
frustration that capability system research does not make that big an
impact as they would like and they think is justified considering the
protection advantages in such systems.  Maybe the points I am making
help to understand why it falls short.  Maybe, just maybe, there has
been to little considerations by capability research to other
demands than protection.

This is particularly relevant if you need to break legacy
compatibility.  Who buys the cat in a bag?

> > People are very ingenious in overcoming protection
> > measures when they want to get the job done, there is a reason why
> > bosses give their passwords to secretaries.
> 
> I'm not sure in what sense this is an argument against capabilities.

This is not an argument against capabilities, but it can be an
argument against pervasive use of POLA in some situations.

> I think one could argue that it is an argument in favor of capabilities.
> People are ingenious in bypassing protection measures when those
> protection measures prevent them from getting their work done.  In the
> example you gave, the protection system prevented a user (the boss)
> from delegating her privileges to another user (the secretary).  Today's
> protection systems are all too often like that.  But many capability
> systems have the opposite philosophy: they are built around making
> it easy to delegate privileges, and in a limited and secure fashion.
> In particular, many objcap systems don't try to prevent this kind of
> delegation, whereas many non-objcap system do try to prevent this kind
> of delegation (causing the hilarity you mention).  So I don't understand
> how this counts as a criticism of capability systems.

This can be an advantage of capability systems if there is a
considerable interest in micro-managing the authority.  My prediction
is that in many cases this is not interesting, and people will
continue to bag a large amount of authority in a single package and
delegate it as a whole.  This becomes a disadvantage of capability
systems if it is hard to do the mass-delegation.  Will it be hard?  I
don't know.  You can wave your hands and say that this could be added
on top of a capability system, but most people will be looking for
ready solutions, not for opportunities to build them, so these issues
have to be addressed in advance.

> > The first thing people
> > will add to a capability system (if they can and care about it) is a
> > root capability that gives access to all other capabilities, and they
> > will use it for all sorts of things.
> 
> I'm not sure what you are suggesting here.  Presumably you're not
> suggesting that we all give up and go home?  If the problem statement
> is "doctor, doctor, it hurts when I create and share a root capability",
> the only answer I have is "don't do that, then".

Uh, oh.  I was going in the other direction.  If splitting authority
into micro-managable parts is a burden, sharing a root capability will
come as relieve.

> I guess I don't share your pessimism here.  Let me give you one
> retrospective example where pessimism might have seem warranted at the
> time but where in hindsight things worked out quite a lot better than
> a pessimist might have expected.  Unix sysadmins have long been saying
> "don't do everything as root".  Today this is basically accepted as
> good advice.  Even Microsoft agrees.  Your line of reasoning would
> have suggested that there's no point in trying to teach users not to do
> everything as root because users are always going to do stupid things
> anyway and because users will demand to always log in as root and use
> it for all sorts of things -- but I think history demonstrates that in
> fact this advice has been useful and has had a positive impact.  It's
> a good thing Unix sysadmins didn't treat this as a lost cause.

I don't quite understand this example.  Chance is that most users of
Ubuntu don't even know what a "root" is.  They enter the administrator
password in the dialog whenever they are asked (and because they are
asked), and that's about it.  The real progress has been in writing
all these little user interfaces and automatization.  That there is a
dichotomy between a root and a user account in such systems is a
choice that the developers made for the user.

> > Third, functionality.  Every second programmers spend on security they
> >  can't spend on other functionality of the software, so there is an
> > opportunity cost.
> 
> This is a generic argument about spending on security rather
> than about capabilities vs other approaches to a security.

Not necessarily.  Sometimes, security and functionality go hand in
hand, sometimes security seems to be more of an expense.

Take for example versioned file systems: They provide a security
benefit, because they add recoverability, but they also provide a
functional aspect, in keeping a history of changes.

There is no generic argument to be made here: It depends on the
requirements of the situation.  I think that for most applications in
most situations, capability research overvalues protection compared to
other demands.  But that's just my gut feeling.  I can not back this
up with any data.

> > If capability systems go hand in hand with
> > POLA and defensive programming, progress could actually slow down
> > while the GNOME people try to figure out how to do something like
> > D-BUS securely.  It's important to strive for a balance.
> 
> I find this criticism of capabilities a non sequitor.  You can
> apply this criticism to any approach to security: just replace
> "capability systems" with any other kind of security technology,
> and read your sentence again.

Same response as under "functionality".

> I wonder if what you mean is that there are tradeoffs: making a
> system more secure has costs, and we have to balance the costs against
> the benefits.  Well, that seems pretty uncontroversial to me, but it's
> hard to see what this has to do with whether we should use capabilities
> or not.

I don't see it quite as black and white.  Security is not the
flip-side of a coin.  Security is a response to demands, but the
demands are conflicting.  Capability systems are great, but only, in
my opinion, if your demands are very narrowly focussed on a certain
set of priorities.  I am sure there are several real world
applications where properties of capability systems align very well
with demands.  But if you want to know why capability system concepts
have not been adopted by the masses, I think it is just as important
to look at what capability systems have (or have not) to offer, as it
is to look at other issues.

I am using the term "capability system" here in the sense defined at
the beginning of this mail, to be as specific as possible.  I
understand that in the most abstract sense, a capability is just an
object handle, and that this allows for flexible composition of
systems with arbitrary properties.

Thanks,
Marcus