[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
Fri, 2 Feb 2001 17:29:12 -0000
David Wagner wrote:
> Tyler Close wrote:
> >The ACL model requires that the invokee check access.
> That's not correct. There's a reference monitor (often
> part of the OS)
> whose job it is to check access.
If you substitute the words "reference monitor" for "invokee", does my
sentence parse better for you? In terms of the logic of the check that
is being done, I see no possible differentiation between these two
I am surprised that you would toss my entire argument on account of
this terminology preference.
> Of course we can't leave
> it up to the
> subject to check access; it is the subject we are trying to
> restrain, so
> we can't trust the subject to do the checking.
In an earlier email, I had mistakenly mixed up the words subject and
object. I did not make that same mistake in the email you are replying
to. I don't understand the relevance of your comment.
> >> I don't understand. It seems to me that it is about
> access control
> >> at the level of *accounts*. That's different.
> >How do you distinguish an account from a pointer to an
> account object?
> Sounds like you just did! It's the difference between a value and a
> reference to a value. Is that what you meant?
> Maybe the following will help you: All pointers to account
> objects are
> pointers, but the reverse is not true. If it is true that
> we only need
> access control at the level of accounts, we only need any
> access control
> on account objects; we don't need access control on
> pointers to other
> types of objects, for instance.
You're really confusing me. We were talking about the granularity of
access checks and you were saying that doing access checks at the
granularity of individual pointers is not something you find useful. I
assumed this meant, you were accustomed to a more coarse granularity.
Your following messages certainly indicated that. Your latest
comments don't seem to have anything to do with granularity.
> >If programmers in an ACL system stuck with the policy that every
> >distinct authority be given its own seperate delegation supporting
> Can you help me parse this sentence? What's a "authority"?
> Do you just
> mean a type of access (e.g., `read', `write', ...)?
In this context, I was using the word authority in the same sense that
the POLA (Principle of Least Authority) uses it. Maybe you would be
happier with the word privilege.
> a "delegation
> supporting ACL"?
I attached the word delegation to make clear that I meant the type of
ACL that you mean and not the type of ACL that MarkM means. I believe
we've already had a long discussion on this point.
> Why are you assigning an ACL to each
> authority, rather
> than to each object?
I mean "Object" in terms of the ACL terminology that you use. I do not
mean object in terms of the Mint "object" that Hal coded.
> You said, e.g., "the ACL model encourages incomplete modelling of
> the application access table", but I don't understand:
> Lampson's paper
> describes both ACL's and capabilities as just two different ways of
> representing the same concept (i.e., the access control matrix)
> efficiently in memory.
I was not talking about what it can do, but what it does do. You seem
unable to consider the differences. In your estimation, is Hal's Mint
an exhibition of an ACL design? Is Java an exhibition of an ACL
Even if you wish to consider some hypothetical ACL system, that
hypothetical system has to have an interface for telling the
"Reference Monitor" what checks to do. My argument is that the
existence of such an interface means that it is very likely that the
access table that the "Reference Monitor" is checking does not
correspond to the actual access table of the privileges in the
> As for the rest, I understand the purpose and value of combining
> designation and authority, and I agree that it seems to be a nice
> benefit. I'd like to understand, though, whether I can obtain some
> of this benefit without requiring a radical change to a new
> programming language, operating system, and so on ... especially the
> language part, because I'm a little skeptical on whether type-safe
> languages can provide the level of assurance I'd like. That's why
> I'm asking these questions: Not because I have a special aversion
> to E or to capabilities, but because I'd to understand what the
> benefits are, where they're coming from, and whether it's possible
> to reap partial benefits with a less radical change to the way I
> program. In other words, can I pay only some of the cost and get
> some of the benefits back?
Sure, one source of the benefits is the guarantee that the "Reference
monitor" will be checking an access table that corresponds to the
actual access table of the application. To gain this advantage under
an ACL system, you would exercise extreme care in setting up your ACL
lists. You get this advantage at the price of useability.