[cap-talk] A question on capabilities - charts review + comments

[Jed at Webstart]

At 09:22 PM 6/11/2006, David Wagner wrote:
>I gave a talk at PLAS06 yesterday on object capabilities and
>language-based capability systems.  My slides, if anyone is interested,
>are here:
>   http://www.cs.berkeley.edu/~daw/talks/PLAS06.ps

Interesting presentation.  The idea of presenting capabilities to
a non-aware audience is of course very close to the hearts of
many people on this list.

I'd like to make some comments on the presentation and perhaps
elicit thoughts from others.

R.e. the very powerful Solitaire program:  While I think that's a
good example, I think that perhaps by itself it isn't as compelling
as it might be.  People could think, oh, I know about not picking
up questionable games and such.  I'm not at risk from such a threat.

I suggest following that up with some additional examples.  Here
are some I suggest, thought I'd like to hear from others and possibly
work up a "best practices" set of examples:

2.  Programs that people are required to run such as codecs
for video formats that are relatively little used and examined.

3.  Programs that through things like macro facilities cannot
be trusted but by default are - e.g. Microsoft Word.  Word
generally needs very few authorities (e.g. access to one file
to work on, perhaps some temp files, display, etc. - much
like Solitaire), but it is also given "ambient authority".  This
might not seem so bad until it gets used as a vector to take
over your system by a macro.

I love your discussion of "ambient authority".  That's a bit how I
felt about that term when I picking it up from this community.
I've been happy to adopt the term to have something to use to
discuss the obvious problem.

During that ambient authority discussion I suggest you also
mention authority to access the network and authority to read
the users keyboard input and display output.  These are important
ambient authorities that go beyond the typical "file" examples.

I believe your chart titled "Object capabilities make POLA easy"
is a lovely start.  However, I believe it needs to be augmented
to describe where the meat of the authority communication
happens, namely at the subroutine (whether local or "remote)
level.  This is exactly the level where parameters are normally
communicated.  In an object capability world such parameters
can be permissions in addition to information (like integers,
strings, etc.).

Just a terminology point - if you go to so much trouble to
clarify that "authority" is a transitive closure of <what?>,
I think you need to describe what it's a transitive closure
of.  I think "permission"s is the right term there, but perhaps
others will wish to correct me.

The main value to me of capabilities is that down at the
program to program communication level, permissions
can be communicated just like any information parameter,
making POLA quite natural and essentially automatic at
that level - as long as there isn't an overriding ambient
authority that messes things up.

I believe that before you jump into your chart "language support
for capabilities" you should make clear that capabilities can
show up at many levels and in many forms (thought perhaps
translatable at some point - i.e. my "standard"s point).  In
particular one can see capabilities at the network level
where I think the Wideword example, e.g.:

https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D

is particularly compelling.  There one can actually see and
manipulate capabilities.  They can be sent in email, etc.
This is a network level of capability (permission token).
I realize of course that such an example can bring up the
issue of inappropriate use of "password"s, but I consider that
a positive and not a negative.

At a lower level capabilities can show up in operating systems,
e.g. the file descriptor examples you refer to.  Such capabilities
are permission tokens supported by the operating system (or
something provided by it like file descriptors) that can be used
to communicate permissions between processes.

At the finest level of granularity capabilities can appear as
objects in a language context, which seems to be where you
focus your attention.

I'm not sure how much to comment on your confused deputy
discussion.  To me the compiler example is rather disconnected
from any reality that most people (users and developers) actually
deal with.  I'm not sure what to suggest.  At a very minor editing
level I think where you say:

"In the capability paradigm, we wouldn't write programs that accept
arguments that are strings representing filenames; that's not the capability
way. Instead, they'd be written to receive capabilities to the files."

You could make the tense more definite, e.g.:

"In the capability paradigm we don't write programs that accept
arguments that are strings representing filenames; that's not the capability
way. Instead, they're written to receive capabilities to the files."

This sort of programming has of course been done many, many
times over the years - even in the relative rarity of the capability paradigm.

Beyond that I'm not sure what to suggest about this area, but it
feels a bit abstruse to me.

Regarding the minor issue of getting the billing file permission to
the compiler:  It seems to me that could be simply done when the
compiler service is initialized.  I'm not sure this issue that seems
minor to me needs to be brought up as a "good question".

R.e. reasoning about authority, when you say:

"Now I want to move on to my second subject: how object capability
systems make it easier to reason about the flow of authority in a program."

I suggest augmenting that sentence a bit to:

"Now I want to move on to my second subject: how object capability
systems make it easier to reason about the flow of authority in a
program, set of programs, or even in a distributed system."

When you get to "Defensive consistency" and say:

"For instance, maybe Alice provides a MP3 encoding service. If Yolanda
is an honest client of Alice, and Zack a malicious client, we don't want
Zack to be able to attack Yolanda by confusing Alice into providing
incorrect results to Yolanda."

I think you're getting close to the heart of the value that capability
based permission communication provides.  I think it's important to
mention there what would be happening in an ambient authority
model.  In that case Alice gets all Yolanda's authority when invoked
on behalf of Yolanda and all of Zack's authority when invoked on
behalf of Zack.  In that scenario I think it's rather easier to imagine
how Alice can end up spreading pollution from Zack to Yolanda and
others, whether as a confused deputy or otherwise.

You do get to this capability value when you reach your chart,
"Object capabilities enable local reasoning", at least I think that's
what you're getting at.  I admit that the logger example on that
chart doesn't convey the value to me.  When you say, "Notice
how easy that was?" and contrast it with a monolithic C or C++
application where you argue you would be forced to "tediously
inspect every line of course code in the entire application", isn't
that essentially what you're doing with the "capability" reasoning
about the logger - namely searching the entire source  to see what
it does to the log file.  Perhaps I'm missing the fundamental point
here?  I don't see how it points out the value of capabilities to
enable local reasoning - though I do believe they do.

Regarding your chart, "Design guideline: Capability discipline",
I think I've used that term "capability discipline" in another way.
Perhaps we can get a reading from the list members on how that
term should be used.

 From my perspective the term "capability discipline" refers to
the use of permissions strictly in terms of the standard form
for capabilities.  At the highest level it assures no designation
without authority.  For me it goes a bit beyond using capabilities
(combining designation and authority) for communicating
permissions to assuring that any use of a capability could have
another capability substituted for it's use and, as long as the
replies were the same to requests, the user of the capability
shouldn't be able to tell the difference.

I did a little Googling for this "capability discipline" phrase.  I'm
not sure that phrase has a generally accepted use.  Do others
believe it does?

After reading the rest of your "capability discipline" chart I conclude
that you're using the term "capability discipline" in a rather narrow
form - namely to mean that when a permission to a resource is
communicated, no other permissions come along for the ride.
In capability systems it's certainly possible to have capabilities
with what one might consider hanging on permissions.  Generally
it doesn't occur to one to set up such capabilities and it seems
unwise and unnatural, but it is possible.  I don't believe I've heard
the term "capability discipline" used in the way you seem to be
using it.

What do others think?

Regarding your chart, "Immutable objects simplify reasoning"
and the statement that "immutable objects convey no authority."
Perhaps I'm misunderstanding something here.  What about
a capability to a read-only file?  I believe that's immutable but
also conveys an authority.  Am I reading this wrong?

R.e. Further Reading - I at least recommend the "Capability
Myths Demolished" paper.  I think that particularly for security
folks that's important reading.


In the remainder I respond to your content in your message beyond
reading your presentation:

>I got one question afterwards that I didn't have a great answer to,
>and I'm curious what others response might be.  The question: Suppose
>Alice has a powerful capability, and Alice and Bob have a communication
>channel over which they can talk to each other.  Ok, granted, we can't
>prevent Alice from sharing her authority with Bob, if she really wants
>to, since she can always proxy for Bob.  But what about the risk of Alice
>unintentionally leaking her capability to Bob?  Do capability systems have
>a good story about how to deal with that?  (And yes, we recognize that
>if Alice and Bob are completely isolated from each other, then that's
>one case where capability systems have a good story, but that case is
>too restrictive, and the questioner was really asking whether there are
>any other cases where capability systems can help out with this risk).

I agree with the previous comments on this topic.  Namely that as you
say Alice can't be prevented from sharing if it's her (program's) wish,
so "Mandatory Access Controls" are both effectively useless
and a very bad (complex and essentially unusable) idea.  There are
many ways to help Alice care for a powerful authority which I agree
generally shouldn't be communicated "willy nilly".

>I think the questioner was also trying to understand whether there might
>be cases where it would be useful for a system administrator to be able
>to restrict the transfer of capabilities from Alice to Bob somehow to
>prevent some sort of unintentional leakage.

In my opinion such questions come from muddy thinking in a MAC
world.

>I think the questioner may
>have come from a mandatory access control background, where one of the
>often-stated motivations for MAC is that the sysadmin ought to be able
>to prevent Alice from leaking her stuff to Bob.

There you go.

>Does anyone have reactions to that sort of question?  I'm curious to
>hear what others think about the topic.

I think this topic has been discussed ad nauseam on this list.
I think it's well known that I react, uh, strongly to questions of
that sort.

>P.S. If others are interested in what other questions I got, here are
>some of them:
>- Can capability systems help protect confidentiality and enforce
>information flow policies?  (My view: No, capabilities don't give you much
>leverage there.  To the extent that you can use access control to prevent
>Alice from getting access to the secret in the first, capabilities can
>help you get that access control right, but once Alice knows the secret,
>it's very hard to prevent her from leaking it -- and capabilities don't
>really help much with the latter problem.)

Capabilities or no capabilities, authorities can be proxied.

>- Can capability systems be used in a distributed environment, for
>instance to help secure mobile agents?

Of course!  and quite naturally - e.g. YURLs, widewords, and many
other schemes over the years.  I think it would be great to haven
an Internet standard in this area (I tried first in RFC 712 in 1976, and
later published some papers suggesting means for such standardization).

>- Can you mix capability-style code with non-capability style code?
>For instance, can you mix some new code written in the capability way
>with old legacy code not written in the capability way?  (My view: You
>can, and you can get some partial benefits, but to be honest, there are
>some real limitations on how much this can help you, and the boundary
>between the capability and non-capability world is often a source of
>both frustration, because of the impedance mismatch, and security holes.
>Capability style programming has a tendency to pervade the system,
>in that you have to change the entire system from the ground up if you
>really want to do things the capability way, which does make it harder
>to adopt capabilities incrementally.)

Hmmm.  I not sure this is so much an issue of style of code vs. one of
the environment for managing authorities.  What good does it do one
to run capability-style code in an ambient authority environment (e.g.
Unix or Windows)?  You first have to essentially defeat all the ambient
authority sharing (e.g. Plash or Polaris) before any value can be achieved
by any "capability style" code, and even then some sort of authority
token sharing mechanism is needed for the "capability-style" code
to use.

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