[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)

David Wagner daw@mozart.cs.berkeley.edu
1 Feb 2001 05:52:23 GMT

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)

Slightly more precisely, I think an ACL system is one where the
access authorities are held with the object as opposed to being
held by the subjects.  (If the objects all live at a central location,
the two definitions are equivalent, but if the objects are distributed,
ACL's need not imply a centralized security database.)

Your main criticism seems to be that this would imply a very large
database.  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)?

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
problem?  After all, we could make the same argument about capabilities
systems.  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.

I think you may be getting thrown a little bit astray by thinking
"capabilities = pointers (lightweight)", "ACL's = databases (heavyweight)".
I don't tend to find that I need access control on such a fine level
of granularity as pointers.

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.

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.  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.