[cap-talk] Don't understand capabilities
lists at notatla.org.uk
lists at notatla.org.uk
Thu Oct 26 22:11:38 CDT 2006
Jed,
> I consider this: At 01:56 AM 10/25/2006, lists at notatla.org.uk wrote:
> >...After much reading on capabilities I still don't think I
> >understand them but
> quite embarrassing. How can this be?
I'm probably as embarrassed as you are. I'm going to describe the way
I see capabilities and this should help show where our minds are not
meeting. I'm generally encouraged by your mail that I have not missed
the fundamentals, merely failed to put all the pieces together.
> Since Wikipedia seems to be a good source of shared wisdom these
> days, perhaps we should ask, What is wrong with the description in:
> http://en.wikipedia.org/wiki/Capability-based_security
>
> Getting this right seems to me vital to our effort/focus on this
> list. Perhaps we should discuss tuning up that page?
OK, let's list some attempts at a definition of a capability and
then some examples and see how correct and consistent they are.
Definitions
===========
D1 Jed's words:
"All capabilities are is communicable references to objects that
convey both designation (identify the object) and permission (grant
some sort of access to the object)."
Plus a supplement derived from the rest of his mail I'm replying to:
D1.s1
There's a reason to think the capability is the _only_ way to affect the
underlying object.
Whether it's fair or not I'm going to take this definition as literally
as I can and see where it leads. So if you left out something as not worth
stating then I'm interpreting this definition as not including it. You
said it was "VERY simple" and I'm going to act as if I believe you. :)
D2 The article http://www.eros-os.org/essays/capintro.html is more of a
description but I'll try to use it as a definition (largely ignoring the
warning "This essay is informal. My goal here is to get across the core
of an idea").
D3 The Wikipedia article you referenced
http://en.wikipedia.org/wiki/Capability-based_security
says
"A capability is defined to be a protected object reference which, by virtue
of its possession by a user process, grants that process the capability (hence
the name) to interact with an object in certain ways. ..."
(Is this a reference that's protected or a reference to a protected object?)
D4 This starts like D1:
"All capabilities are is communicable references to objects that
convey both designation (identify the object) and permission (grant
some sort of access to the object)."
D4.s1 There's a system and only inside this system is the capability meaningful.
(Kind of like a function definition has a domain as well as a way to calculate y from x.)
D4.s2 The system contains a part that requires the capability to access the object.
(I'll call this "the customer".)
D4.s3 The system contains a part that has some other means to access the object, and uses the
capability data in a different way from "the customer".
(You used the term "the servicer" and I think this is that.)
D4.s4 The capability is large and randomly-generated to prevent it being guessed either from
scratch or by modifying another capability.
(The capability is being used as a security mechanism.)
Examples
========
E1 An URL may be a capability. This one for example (in a non-indexable directory):
http://www.notatla.org.uk/MISC/cap-talk/2f065fcf1cf9c77aad421a6ae0dc02a835b94243.html
This is very simple beacuse it's just a file for reading.
Tested by D1: It's a capability - communicable data etc.
Tested by D2: It's a capability - communicable data etc.
Tested by D3: I think it is, but couldn't prove it to a sceptic.
Tested by D4: It's a capability - communicable data etc.
1: The system is roughly the Internet - anyone who can connect to my port 80.
2: The customer is the browser and has no means to access the file except by the URL.
3: The servicer is the webserver - it has access to this file and others and uses the
URL as a way to find this specific file and not as a way to obtain authority.
4: The SHA1 value is supposed to satisfy D4.s4. A website's session IDs would be
unsatisfactory as capabilities if they were consecutive integers.
E2 Bishop's queue tokens may be capabilities.
I refer to http://nob.cs.ucdavis.edu/bishop/secprog/robust.html
where about half-way through the article he introduces "Example of a Robust Library"
and I think the encrypted tokens of the queue manager are capabilities.
I think this passes all of D1-D4.
In the D4 model:
1: The system is any instance of any program produced as described in the article.
2: The customer is the program excluding the library.
3: The servicers are the functions that have the underlying data as static variables.
4: The tokens are produced so as to satisfy D4 (and not merely as pointers).
E3 A kerberos ticket may be a capability - presented for the first tiime, in its lifetime
and with a verifier to prove freshness. I've seen an article that used kerberos tickets
as an example of capabilities.
Tested by D1: yes
Tested by D2: Perhaps yes.
But if I force on it more strictness that is perhaps proper I notice
the ticket conveys who is using it, contrary to the text
"Note that the car key doesn't know that it's me starting the car"
and I might say this fails to meet D2.
Tested by D3: I expect so.
Tested by D4: yes
1: The system is a kerberos realm or set of cooperating realms.
2: The customer is probably a program running on the users's desktop.
3: The servicer is a server process.
4: The tokens are produced cryptographically by a TGS.
E4 A file descriptor may be a capability, as seen in
http://en.wikipedia.org/wiki/Capability-based_security
After a successful call to
int fd=open("/etc/passwd", O_RDWR);
the descriptor is called a capability.
Now this gets to the meat of my post and where I know I'm confused when I try
to interpret this article. In fact I'm going to attempt several interpretations,
that have flaws and are here to be debunked.
E4.i1 The "int fd" is the capability and the whole process has the relevant authority.
Tested by D1: An int is communicable data. The problem is it doesn't convey authority
so you can't give away access by conveying an int to another process, nor
by shouting "3" in a crowded computer lab. (And taking D1 literally there
is no system boundary outside which it isn't supposed to work.)
Tested by D2: Same as D1.
Tested by D3: I've twisted the interpretation - the "int fd" itself is not the capability.
Tested by D4: This satisfies some but not all parts of the model.
1: The system is this process - the int won't have the same meaning outside it.
2: The customer is hard to spot - the entire process has the authority to use
this descriptor. Use of the int is designation without authority.
3: The servicer doesn't exist as a part of the system separate from the customer.
4: The int is easily guessed either from a small space (31-bits) or by proximity
to some other descriptor.
E4.i2 The "int fd" is the capability and the kernel part has the relevant authority.
Tested by D1: An int is communicable data. The problem is it doesn't convey authority
so you can't give away access by conveying an int to another process, nor
by shouting "3" in the computer lab. (And taking D1 literally there is no
system boundary outside which it isn't supposed to work.)
Tested by D2: Same as D1.
Tested by D3: The article presents the descriptor in kernel memory as the capability,
as opposed to the simple, communicable int fd.
Tested by D4: This satisfies most of the model.
1: The system is a process - the int won't have the same meaning outside it.
2: The customer is the userspace part of the process.
3: The servicer is a system call that uses the fd internally for designation.
4: The int is easily guessed either from a small space (such as 31-bits) or by
proximity to some other descriptor.
So other than failing D4.s4 it seems E4.i2 might be a proper interpretation of
a capability system, but it suffers from the fact that this interpretation deviates
from the article's text. Is it me or the article that's (more) confused?
E4.i3 A blob of kernel memory is the capability and communication of it means
descriptor-passing. This seems closest to what it literally says.
Tested by D1: This fails my test of "VERY simple".
Tested by D2: Maybe passes - but the servicer does get to know who the user is.
Tested by D3: This should pass if this is really the meaning of the article.
Tested by D4: I question whether you'd call this ordinary communicable data because
it's not just data; you need to introduce it in a certain place.
1: The system is any process containing this descriptor.
2: The customer is the userspace part of such a process and doesn't have
the capability. What it has is an int.
3: The servicer is a system call.
4: The descriptor is in protected memory so guessing seems irrelevant.
You asked what's wrong with the wikipedia page - well now I've tied myself
in knots trying to understand it you may be able to see. I wonder whether
the file descriptor example makes a good introduction to the subject.
My background is monocultural Unix but I'm a protester against ambient authority
which is a kind of default permit. I don't suppose these articles are news to
anybody here:
Ranum on default permit etc:
http://www.ranum.com/security/computer_security/editorials/dumb/
Ioannidis, Bellovin & Smith on avoiding identity-based authority:
http://www.cs.columbia.edu/~smb/papers/subos.pdf
NSA on inevitability of failure - shortcomings in current OS design:
http://www.jya.com/paperF1.htm
To lift a paragraph from another mail of yours - I'm not the person you're describing here.
> I don't think that we as capability advocates should hang our hats
> on the Confused Deputy problem (at least in the limited sense
> defined by Norm). It simply isn't considered a "problem" on Unix.
> Perhaps there is some awkwardness (e.g. with SUID programs
> that are not SUID root where in general the program can't run with
> the client's UID - i.e. no mutual suspicion), but Unix is and has
> been a working system for many, many years and people who think
> along Unix lines simply don't feel the need (really need) for
> POLA/capabilities. Generally they feel that capabilities would make
> Unix horrifically complex and unusable and would result in a
> worse system.
I'll admit that I'm backward on microkernel implementation details but I hope
that's not an obstacle to understanding principles of capability systems.
In fact if my D4 and E1 are good I've already made some simple web-based ones.
Hopefully now my misunderstanding is evident and can be corrected.
"Antonomasia", writing from lists@ for list purposes
More information about the cap-talk
mailing list