[cap-talk] RE: OS security discussion, restricted access proc
esses, etc. - back to basics
alan.karp at hp.com
Wed May 5 12:53:52 EDT 2004
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Tuesday, May 04, 2004 7:35 PM
> To: Capability Talk
> Subject: [cap-talk] RE: OS security discussion, restricted
> access processes, etc. - back to basics
> How would you refer to the Public Key mechanism described in:
> Would you consider that mechanism capabilities as descriptors?
You know what? I was just writing a long explanation of what I mean by "capabilities as bits" and I realized that I was describing password capabilities. That's a secret that can be used as a capability by anyone who knows the secret, right? So, either "capabilities as data" or "capabilities as bits" is a useful term for the capabilities tied to a private key, be it MD#s13 or SPKI attribute certificates used by e-speak.
Let me summarize what I think we have.
1. Capabilities as designators, capability list -> DvH
2. Password capabilities -> E language Swiss numbers
3. Capabilities as bits/data -> MD#s13, e-speak use of SPKI
4. Access list -> DCCS, MD
2 and 3 extend across the network naturally. You showed how to extend 4, and CU showed how to extend 1.
> Right. I was trying to explore the whole space of such
> network mechanisms
> as I could imagine them. The DCCS essentially uses the access list
> mechanism discussed
> in Managing Domains - though it includes the flaw that allows the
> "Reflection Problem" exploit. NLTSS (the OS who's
> development I led at
> LLNL) was like Amoeba
> in that it used what amounted to passwords for capabilities. The
> alternative mechanisms in Managing Domains were proposals for
> NLTSS that
> weren't implemented.
> We felt the Public Key mechanism was the most promising, but
> at that time
> no suitable Public Key algorithms were available.
Sorry. I was confused because I didn't catch that DCCS was using an access list, too. The key point is that a given capability has the same index for all processes in DCCS. Any process can reference the capability at index 7, and you need a second mechanism to see if that's a legitimate request. In the capability list schemes I know, each process has a separate list. That means that the capability at index 7 for one process can be different than the capability index 7 for another process. So, if a capability doesn't appear in the list for a process, it can't even reference it, and there's no need for checking. CU uses the latter approach.
> That list, in Figure 4 termed the "Support list" under Host
> B, is specific
> to the Network server process, but it is servicing all remote
> requests of
> resources on its system. Any other host system (e.g. C) that
> was going to
> access that capability identified by "capability no." would
> refer to the
> same "capability no.". The only way Host B has of knowing
> which other
> systems actually have the right to access that capability is
> by keeping an
> access list (what I called a bit vector in that paper).
That's the step I missed.
It seems that you're saying there are separate lists for local and remote processes. Is that right?
> However, this is more analogous to an internal resource
> table that
> isn't shown in Firgure 4 of the MD paper. Perhaps the
> confusion is because
> I show the resource table in DCCS and I show the access list
> in MD, but in
> reality both mechanisms require both.
Yep. That was exactly what confused me.
> Almost. The Sneak uses a carefully selected portion of the
> (first proposed) access list protocol to "send" a capability (that it
> doesn't have) to "Reflector". It doesn't send the message to
> the Server
> saying "List Reflector" because in any case the Server would
> reject such a
> request (Sneak isn't on the access list for the resource).
> It just sends
> the message to Reflector with the capability reference (index, name,
> whatever). Since the Reflector in the inadequate protocol
> (like DCCS used)
> doesn't get any independent confirmation from the Server, it
> has no choice
> but to accept the right passed as genuine. If Reflector
> didn't have the
> right to begin with, no harm would be done. However, if
> Reflector does
> have the right to begin with, then, when it sends the
> capability back to
> Sneak (that is what a Reflector does, after all - much like a
> server), it will follow the protocol faithfully to communicate the
> capability to Sneak. In doing so it will ask the Server to
> add Sneak to
> the access list.
> This same problem exists in DCCS.
The problem appears to arise from separating designation, the capability index, from authority, the right to use it. I learned the significance of keeping designation and authority together from Norm. CU didn't get this quite right, but the attacker needed to exploit a bug, not normal behavior.
> By "parameter" do you mean a "kernel" mediated descriptor?
Yes, sort of.
> If the message
> flowed out on a network, what would the bits look like?
It's a bit involved to describe here. Section 3 of
is the best write up. Just ignore the "split" in split capabilities.
> The above property of course holds for all descriptor based
> (classical ala
> Dennis and Van Horn) capability based systems. What I was
> exploring in
> DCCS and in MD was mechanism for communicating rights on a network.
So were we with CU. We did it by having pairwise mapping tables at each step between the endpoints.
> Interesting. Perhaps I'm not understanding. What I
> understood from the
> above was that every time a right was forwarded, it was
> forwarded as a
> Proxy. That would mean if a right was communicated 100 times
> (P1 to P2 to
> P3 ... to P100), when it was invoked it would have to be
> proxied by every
> process in the chain in order to fulfill its request. What
> did I miss?
You could certainly have a chain that long, but we rarely went more than three steps. If the tree is bushy, 100 branches per node, then I can reach a resource on any of 1,000,000 machines in no more than 2 hops. If you did have along chain, you could always request that it be shortened by introduction.
> Let me share my thoughts on these to see if perhaps by hearing your
> responses I can better understand.
Let's make sure we've identified the parties. I'm assuming that Alice is the provider of some service/resource that Carol wishes to use and that Bob is forwarding Carol's requests to Alice.
> >1. Bob may be a certified business partner, and Carol
> doesn't meet Alice's
> >corporate requirements.
> Yet Alice proxies all of Bob's requests through to Carol.
All of Carol's requests to Alice come through Bob.
> How does that
> protect Bob? If there are
> some requests that Alice doesn't proxy (e.g. to protect Bob),
> then I could
Indeed, Bob can refuse to forward some of Carol's requests. If Bob proxies for many machines in an enterprise, Bob is a convenient place to embody corporate policy. In this regard, he is acting sort of like a packet inspection firewall.
> >2. Carol may not protect her machines well enough for Alice
> to risk a
> >direct connection to her.
If Carol's machine is compromised, it can only be used to attack Bob, not Alice. Since Alice may be providing a mission critical service to other machines no being proxied by Bob, the distinction is important.
> >3. Carol may not have a payment scheme or credit rating that
> Alice will
> Hmmm. Are those names right? How does Bob get into the act above?
> >4. Bob may be inside Alice's firewall while Carol is outside.
> This one I can understand. If Bob can't communicate with
> Carol, then of course
> he must have a proxy to manage the communication. Presumably any such
> communication would be value added or in some sense it is
> defeating any
> putative value in the firewall.
> >5. Alice may be controlling the number of requests per
> second from Bob.
> Adding value - again I can understand.
> >6. Alice may not want to expend the resources for a new connection.
> Why would Alice need additional resources if Bob was able to
> directly with Carol? Is that because there would have to be
> a connection
> Bob and Carol? I guess you are assuming that Alice continues
> to hold her
> connection to both Bob and to Carol?
I think you're confused by who's in what role. Bob is forwarding Carol's requests to Alice.
CU was connection based, and each connection used some resources. If Bob and Carol both connected, Alice would consume twice the resources. Of course, if Bob's only purpose was to proxy for Carol, there's no benefit. Most often, though, Bob would proxy for many machines.
> Hmmm. I'm afraid I'm still missing something here. I hope
> the discussion
> above helps you
> understand the above text, because at this point I still
> don't understand
> where the differences are.
Does my earlier comment clarify this?
> I think our system, even with the private key mechanism,
> would fail to meet
> his criteria if it didn't treat classification as a property
> of the bits
> that flow (e.g. out onto the network).
Because of the inalienable right to transfer, right?
> If I'm understanding the above such "amplification" sounds
> like a good
> thing to me. No?
> What can Carol do with the non-proxied (direct,
> capabilities as bits) that she can't do with the proxies? If
> foo and bar
> were RW file capabilities and "combine" meant some sort of
> merging of their
> data then it would seem that Carol could do the merging in
> either case. No?
That's why I didn't use file copy as an example. Say that you don't want anyone to see the data contained in foo and bar, so you don't provide a "get" method. You'd like some people, but not just anyone, to do a calculation with them. In this case "combine" can be "add and return the sum". Only someone with both the foo and bar capabilities can see the sum. Other people are allowed to combine foo and qux, and others, bar and qux.
To return to the example, if Carol's only access is via Alice, who holds only foo and qux capabilities, and Bob, who holds only bar and qux capabilities, Carol can not combine foo and bar. If Alice and Bob have the inalienable right to transfer their capabilities to Carol, then Carol can combine foo and bar.
> >I want to thank you for this discussion. I haven't had to
> think this hard
> >in quite a while.
> I'm also enjoying it. Thanks for taking the time for such a thorough
> discussion Alan!
> --Jed http://www.nersc.gov/~jed/
> cap-talk mailing list
> cap-talk at mail.eros-os.org
Technical Computing Research Group
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040505/e743374f/AlanHKarp.obj
More information about the cap-talk