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

David Wagner daw@mozart.cs.berkeley.edu
2 Feb 2001 00:25:22 GMT

Tyler Close wrote:
>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.

I'm not sure I'm convinced, but I'd be happy to grant you this point,
for the purposes of this discussion.  A 2x performance loss probably
isn't especially fatal; and, anyway, I'm more interested in learning
about the semantics and the assurance level one can get from various
security mechanisms.

>David Wagner wrote:
>> 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?
>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.

I still don't understand.  ACL's are just a mechanism.  You need to
start with a security policy, and if that policy doesn't give you enough
information to decide whether a particular object needs to be guarded
in some way, it seems the right answer is to get a better policy.

Now maybe you're worried that, in enumerating the security-relevant
objects, you might have forgotten one.  That's a fair concern.  However,
this concern applies equally to both capabilities and to ACL systems.

The solution, as always, is to use a "default deny" policy.  Thus,
the most appropriate implementation probably is "guard _all_ objects,
except possibly for the ones where you're sure they don't need to be
guarded".  This is fail-safe: If you forgot about some obscure object,
the system won't fail open (insecurely), it'll just prevent you from
getting any work done.

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

If that's true, it's a flaw in the particular implementation, not
a fundamental limitation of ACL's.  (And yes, it is also possible
for an implementation of a capabilities system to have this flaw.)

ACL's aren't magic bullets.  They don't automatically make your
system secure.

>Even the little MintMaker example is all about access control at the
>granularity of pointers. Without it, you fall to the confused deputy.

I don't understand.  It seems to me that it is about access control
at the level of *accounts*.  That's different.

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

Sure, you can think of it that way if you like; it doesn't bother me.
I don't really care what you call it -- I find it more interesting to
try to understand the properties of the security mechanisms available
to us.