[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
Thu, 1 Feb 2001 15:47:31 -0000
David Wagner wrote:
> Tyler Close wrote:
> >Your proposal, as I understand it, is to invert the
> capability model,
> >so that all access authorities are held in a central database, as
> >opposed to being held by the subjects.
> Yes. This is pretty close to the definition of what an ACL is!
> (at least as I understand the term)
Ok, then, I'll accept that. Now let's understand the implications of
this inversion. I believe there are many of great importance. I've
tried to explain a number of them.
> Your main criticism seems to be that this would imply a very large
No, this just happened to be the first one I wrote down. There were 3
in my first reply, followed by another 2, followed by more in my
response to Hal. Most of these are of much greater importance. I wish
I had structured my points better, but what are you gonna do, this is
just email I send out at various times throughout the day.
> But I don't understand this criticism. If there are N
> subject-object pairs (S_i,O_i) with some level of rights, doesn't it
> require O(N) space to store the database, whether the rights are
> stored with the subjects (capabilities) or with the objects (ACL's)?
No, because you split the capability into a designator and an ACL
entry. You doubled the storage. In fact, you probably more than
doubled it because the lists themselves take up space in addition to
the list entries.
> You mention a second criticism: that one has to decide which objects
> will be guarded by ACL's. Well, that may be true, but why is it a
So, I feel very nervous about this given your reputation, but this
would suggest to me that you haven't written much software. Maybe one
of the Javasoft guys could tell us how much time was spent on this
issue for the Java APIs. I'd also be interested to hear if they think
they got it perfectly correct.
> After all, we could make the same argument about
No, one of my main points is that you can't.
> It would be instructive to me if you could
> identify why this
> argument applies with special force to all ACL systems but
> not to any
> capability system.
Take a look at the HalMint discussion with regards to the IRS.
The general problem is that an ACL requires an explicit listing of the
prohibitions, whereas the capability model does not. Prohibitions are
expressed solely in terms of interface and distribution patterns.
> I think you may be getting thrown a little bit astray by thinking
> "capabilities = pointers (lightweight)", "ACL's = databases
> I don't tend to find that I need access control on such a fine level
> of granularity as pointers.
Even the little MintMaker example is all about access control at the
granularity of pointers. Without it, you fall to the confused deputy.
Note that the argument you are making here is exactly the one I
predicted an ACL advocate would make in my response to Jonathan. You
see that your ACLs are too heavyweight and so you want to define
overly broad authority granting actions.
> But, if you like to think about pointers as the unit of
> protection, we
> could compare a pointer-based ACL system with a
> pointer-based capability
> system, where the protection semantics are in both cases enforced by
> a MMU chip.
> In the example capabilities system: Each pointer value also comes
> with an attached, unforgeable cryptographic checksum. The MMU
> generates checksummed pointers as references are created, and
> checks the checksums on each dereference operation.
> In the example ACL system: Each memory location that can
> be referenced
> also has a list of Subject ID's that can access it.
> Each process
> executes under some Subject ID; when you dereference a pointer,
> the MMU checks that the corresponding memory location
> has an entry
> for your current Subject ID.
> You can note that both require substantial overhead, although the
> exact performance comparison is likely to depend on usage.
And if we're using a pointer safe language such as E, this overhead
goes away for a capability based design and remains if we're using
As I pointed out to Hal, the ACL check grows proportionally with the
authorization procedure, whereas it does not for capabilities.
> At this point, you might note that the example pointer-ACL system
> above is susceptible to "Confused Deputy" problems, whereas
> the capability
> example isn't. I agree.
> In general, the "Confused Deputy" problem arises because accesses to
> the ACL-guarded object implicitly uses the Subject ID to
> decide whether
> the access should be granted. Thus, one potential solution
> is to insist
> that all operations to an ACL-guarded object make explicit
> the Subject ID
> they are using to authorize the operation.
Initially, this made no sense to me whatsoever. Then I read Jonathan's
response and saw that you mean for the Subject ID to be a capability.
Seems like a pretty broad capability too. The holder has the right to
be the Subject for any operation. I don't see how this fixes anything.
Interesting that you should turn to capabilities to try to solve the
> This can either lead to
> beneficial explicitness (probably a good thing, if you're trying to
> build secure systems) or unwanted clutter (a bad thing, if
> it just gets
> in the way). This is a tradeoff, and the right answer
> seems to depend
> on the application.
There need not be a tradeoff. See the HalMint thread.