[cap-talk] Loss of control (was: Re: A paper on web-keys)

[Jed Donnelley]

At 04:20 PM 1/31/2008, David Hopwood wrote:
>Jed Donnelley wrote:
>...
> > A pure capability system includes the ability for users to pass 
> the capability
> > to other users.  Because this ability is *not controlled* and 
> capabilities can
> > be stored, determining all the users who have access for a 
> particular object
> > generally is not possible.  This makes a complete DAC implementation,
> > including revocation, very difficult.
>
>"A pure capability system includes the ability for elephants to pass the
>capability to other elephants...
>
>Sorry to be flippant.

No problem - if you consider that technique effective.

Actually the above statement ("includes the ability"),
which is simply the assertion of support for the Granovetter
diagram, seems to me a pretty straight forward statement
that applies to all capability systems.

>I could spend years refuting all the errors of
>logic, correcting misuses and inconsistent uses of terms, and teasing out
>the unstated, often mistaken assumptions in these papers -- but I think that
>designing and building capability systems that refute them by example would
>be a more productive use of time and effort.

I can accept that reasoning.  How do you suggest dealing
with those who either ask about or assert the "lack of
control" that started this thread with the comment
by a reviewer who contributed to the rejection of
Tyler's paper?  Same approach, just let it go and go
off and implement?  At some point you have to sell
what you implement.  I don't see that approach as
effective at that point.  Sometimes the selling also
has to come before the developing.  Your suggested
approach seems to be difficult to apply in that
pre development sales situation.

Sorry for my ignorance, but may I ask what capability
based system you are building?  It's certainly true
that once one or a few visible systems are marketed,
then there will be a coattails effect that others
can ride on.  Do you believe you are developing a
path leading system?  If so, with what application
and in what market?  I'm quite interested to hear
how you've addressed the loss of control concerns
with your application and market.

Perhaps this is a good point for me to bind back
in a discussion we've been having off-list:

I believe the concern about "loss of control" for
access control is the key barrier facing the widespread
acceptance and deployment of capability systems,
and thus POLA computing.  I've been away from
capability computing for many years, from about
1988 until 2004.  When I again got involved I
asked quite a number of people what they now
thought about capability systems, mostly
recent graduate students from CMU, UCB, and
Stanford.    The response is always about
the same:

Capabilities are an interesting idea.  They
do have some valuable properties like POLA.
Capability systems are difficult to get to
perform well.  Most importantly, however, is
that with capability systems you "lose control"?

What do you mean, "lose control" I ask?

The answer comes in many forms such as losing
control over logging and auditing, but mostly
what it comes down to is:

LOSING CONTROL OVER ACCESS CONTROL POLICY.

Capabilities provide flexibility, but with
them you lose control (sound like the
criticism of Tyler's paper? - it is!):

>At 03:11 PM 1/17/2008, Tyler Close wrote:
>One of the WWW 2008 reviewers of this paper wrote:
>
>"Capabilities are *always* easier to implement, and the tradeoff is
>*always* about giving up control."

Why do you lose control of access control policy?
Because any running program can delegate any
access that it likes just by sending a message,
subject to no control (don't tell me about
confinement - programs usually aren't confined
and often can't be, echoing discussion from
Toby).

So here we have a model that is supposed to
be about access control and what does it do?
With it we lose control of access control??!?

What is wrong with this picture??

I believe this is the fundamental barrier that
people run into when promoting systems based
on the capability model - whether as operating
systems, on the network, or I expect even as
language systems.  In language systems the issues
are a bit different and depend on the answer
to the "persistence" question.  I expect there
are some other domains that are effectively
equivalent to the language area - where
you aren't ultimately dealing with access
control for people and can just deal with
POLA for running programs, somewhat like
the Plessey 250 or perhaps something Jonathan
is doing with Coyotos.  I believe the
concerns about such "invisible" applications
of POLA (postfix is another example) are
really not very significant, so there
I expect POLA can flourish - as long as
it stays out of sight.

I don't want capabilities to have to
stay out of sight.  This is why I've
pushed so hard on Horton.  From my
perspective Horton provides a
means to put back the CONTROL that
people feel is missing with the general
("unmodified") capability model.  Until
we get past this feeling of lost
control (e.g. as the questioner at
Google noted, and has been brought up
again and again in discussions about
capability systems - it's always the
same) we aren't going to sell visible
capability systems.  POLA just isn't
worth that loss of control.

At some point later in the discussion
Alan Karp mentioned that in his talks about
capabilities he now emphasizes how one can
maintain control with capability systems.
He wrote:

>At 04:32 PM 1/31/2008, Karp, Alan H wrote:
>
>In my talks I explain three ways.  There are others, such as split 
>capabilities, that I don't bother with.
>
>1. Rights amplification: You need two authorizations to access some 
>critical resource.  One is freely delegated. The other is handed out 
>by the administrator with an admonition not to delegate it.  (We're 
>in the VOC world here.)  One example is the right to read a file and 
>the key to decrypt its contents.  Delegating the right to read to 
>the wrong party does no harm.
>
>2. Interpose a proxy: The Horton approach.
>
>3. Use the Policy Decision Point: Our capabilities are SAML 
>assertions that include the entire delegation chain.  The assertion 
>authorizing access is validated by a service's Policy Decision 
>Point.  It can decide whether or not one of the delegations in the 
>chain violates policy.

I believe that #1 doesn't achieve much of the control
that people feel they need.  E.g. there is no means
for auditing (checking to see who has access to what)
and no means for logging, as capabilities are
communicated without any knowledge or policy
enforcement - the basic problem.

With Horton (#2) there is a good deal more mechanism
required than just a proxy, it requires identities
and mechanisms for tracking, interfaces for auditing,
logging, etc., not to mention interfaces for what
amount to revocation.  Doable I believe, but it
hasn't been done so no capability system has ever
demonstrated such control.

I can't say too much about #3 because I don't know
the details, but when you say "include the entire
delegation chain" it sounds as if you have a great
deal more information (much like Horton sorts
of information) than is available with
traditional (dare I say "unmodified" or classical)
capability systems.

 From my perspective the criticism of capability
systems that they result in loss of control, particularly
for access control policies and management, have
been true in the past and to the present.  To me
it seems as if we are designing mechanisms today
to try to address these issues.  Whether these will
work and convince people (i.e. sell) is difficult
for me to say until we see such systems in practice.

I still believe that the network area (e.g.
Web-keys) is the most important and most
likely to be a path breaker for the capability
paradigm (and thus POLA).  For that application
(access control across organizations on the
Web for things like mash-ups) there is presently
no technical solution.  This to me is an area
where there is an opportunity.  As Alan
Karp said:

>I think you've got to convince people that ACLs
>can't solve their problems but capabilities can.
>Then you can address their objections.

I believe that if we can supply a solution with
capabilities on the Internet that comes with a
solution to the "loss of control" concern
(has auditing, logging, and access control
management with flexible access control policy),
then I think we have a chance to sell such
an implementation, resulting in POLA for
at least the Web.  I believe such an application
can be a path breaker.

--Jed  http://www.webstart.com/jed-signature.html