[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
3 Feb 2001 02:49:17 GMT
Tyler Close wrote:
>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
Oops. I simply misread your email, thought you meant the invoker was
checking the access, not the object. I apologize for the confusion;
the fault was all mine. Please accept my apologies.
I'm still not ready to accept that there is no harm in assuming it
is the invokee who checks the access (although I'm prepared to be convinced).
In practice, the reference monitor may be distinct from the invokee:
e.g., when we're using interposition.
Let me give a more concrete example. Consider system calls. Typically
they trap to a central handler, which might do some general checks before
vectoring to the actual system call code (e.g., that the syscall number
is in the appropriate range, and so on). Do you want to call the code
which does the general checks part of the invokee? I think it is useful
to keep the reference monitor distinct from the object ("target");
although they may be the same entity in some cases, they need not be.
The rest of your argument seemed like it was possibly premised on the
belief that ACL checks will be integrated into the code of the object
("target"), rather than part of a interposed reference monitor.
Since this premise does not seem necessary to me (probably not even
desirable, depending on the specific scenario), maybe we should discuss
it further before getting into the meat of your point? I truly don't
intend to duck your questions, so I apologize if it comes off this way.
>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.
I apologize. I think I must not have understood your question.
You asked: "How do you distinguish an account from a pointer to an
account object?" Could you explain what you meant? I'm sorry to be
>> 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
I agree with you about the importance of distinguishing between what
some implementations do and what is fundamental & required in the concept.
Thank you for pointing this out. Regarding Hal's Mint, I think it would
be fair to view it as using ACL's. However, I think it is probably not
the optimal way to build a Mint using ACL's. My comments above about the
undesirability of having the invokee check the ACL (rather than a
separate, centralized reference monitor) do seem to apply to Hal's code.
I suspect I would be more pleased with Hal's Mint code if the access
checks were separated out. Imagine a call path that eventually modifies
one's balance; I would like the access check on "can the subject modify
the balance?" to be at the end-point, and enforced with a single mechanism,
rather than having to be integrated into every piece of code that might
be involved in such a transaction. I would expect this to have two
benefits: (1) One would be less likely to omit a check; (2) It is easier
to extend the code to provide additional functionality, at less risk to
So, bottom line: Yeah, Hal's code uses ACL's, although maybe not in the
best possible way.