[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
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
>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
>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
>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