[cap-talk] capabilities Q - charts review + comments
Jed at Webstart
donnelley1 at webstart.com
Tue Jun 13 12:14:28 EDT 2006
At 07:07 PM 6/12/2006, David Wagner wrote:
>Thanks for all the advice and feedback on my talk, Jed. I'll keep
>this around for the next time I give this kind of presentation.
To me this sort of presentation is at the core of the POLA/capability
"cause". Any sort of tuning for impact, accuracy, consistency
with shared community beliefs (I think there are some ;-), etc.
seems to me time well spent. Thanks for making such an
>I should also say that I didn't have time to get into everything in the
>slides; what I wrote in the slides is what I hoped to be able to talk
>about, but what I had time for was a subset of that.
No surprise there. You did get into some pretty deep technical
content in the slides.
>...If Logger ensures that "log"
>(and all of the LogEntry references stored there) is closely held
>and cannot escape, then we know that no one else will get a capability
>to the log entries. That kind of reasoning lets us convince ourself
>of the correctness of the logger without looking at the entire source
>of the application. If Logger and LogEntry are implemented correctly,
>we can convince ourselves that the log will be append-only just by
>looking at the source of Logger and LogEntry. That's the kind of thing
>that's just not possible in a language like C or C++.
I get it. It's still difficult/unnatural for me to trust a language system
(e.g. Joe-E), much like it's difficult for me to trust an operating
system or a database server to protect against privilege escalation
attacks. Despite that I understand the concept. I hope someday
we get to the point where sustained attacks are mounted to
achieve privilege escalation in languages and they are better
able to defend their ramparts than operating systems and database
servers have historically been at such defense.
> >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.
>I'm interested to hear how others use the term. If I've misunderstood
>the intention of others here, that would be a good thing to know.
I'd like to hear thoughts on that also. As I say I did some Googling
and didn't get a clear picture. Is there a common understanding of
that "capability discipline" term in the community? What do others
think when they hear "capability discipline" (probably should be
it's own thread)?
> >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?
>I suspect it all depends about what degree of approximation you are
>working at. In my experience, it is typical that the abstraction of
>authority that we reason about is that we reason about ability to cause
>side effects upon the outside world (through overt channels). We usually
>do not attempt to reason about knowledge of secrets. For instance, we
>usually conservatively assume that the number "3" (and all other such
>integer values) are known to everyone. That's a conservative approximation
>of authority. It in some cases may too conservative -- for instance, it
>is too coarse to reason about cryptography (because it assumes all
>secrets are known to everyone), and it is too coarse to reason about
>covert channels (because it only reasons about overt influence over the
>outside world, not covert influence). In essence, it amounts to making
>the conservative assumption that the adversary is a perfect guesser --
>anything the adversary could do if it could correctly guess the content
>of some secrets, we will conservatively assume that the adversary can do.
>I learned this point of view (recognizing that when we are reasoning
>about authority, we are reasoning with conservative approximations of
>authority) from Mark Miller. I hope I haven't done the idea too much
Hmmm. I guess using that reasoning a read-only (fetch-only) capability
to a directory (named bag of capabilities) would not be considered
immutable because by transitivity (closure?) of access the capabilities
in the directory (assume some allow side effects) are available through
the directory? I think this is a case where even if the capabilities are
some sort of protected references, the read-only access to the directory
which is, at first level, side effect free can result in side effects after
capabilities in the directory are fetched.
Of course this example is much like that of a read-only file that contains
secrets (e.g. "data" capabilities such as YURLs) that enable side-effects.
>The reason for making this kind of conservative approximation, where we
>only reason about ability to cause side effects but not about knowledge,
>is that it is an approximation that is both feasible to reason about while
>at the same time being useful. (For instance, while it might be useful if
>we could reason about secrecy, it is often not feasible to reason about
>secrecy or about covert channels.)
Interesting. I've never noticed a problem reasoning about secrecy or
covert channels, but perhaps I'm using too loose a notion of "reasoning".
I've often observed that efforts at tighter reasoning about security
(e.g. provably secure operating systems, just to pick one famous
example) often simplify models to the point of leaving out critical
practical "details". It's certainly challenging finding a reasoning
level that's both firm enough to draw solid conclusions and inclusive
enough to be relevant to the real world.
More information about the cap-talk