[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
Sat, 3 Feb 2001 13:50:51 -0000
David Wagner wrote:
> 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.
No problem. The initial fault probably lays with me in the way I mixed
up the terms "Subject" and "Object" in my message to Zooko. You were
no doubt reading with this coloring your judgement.
> 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.
I think the problem is that we are confusing two arguments here. I
think you are arguing the "code reuse" argument. In this argument, the
capability side claims that ACL checks are tightly coupled with the
"Object"; thereby inhibiting code reuse.
I am making a related, but separate argument in this thread. I am
arguing that the interface that an ACL system provides encourages the
programmer to build an incomplete model of the application's access
table. I believe the way in which one defines checks in an ACL system
is independent from the way that actual priveleges are defined in the
application. This opens the possibility that the ACL system is not
performing checks that it should be. I tried to relate this argument
to your Lampson access table view of the system by showing that the
actual checks being done by the ACL system form an incomplete model of
the theoretical access table for the application. In a capability
system, the mechanism used to define priveleges is the same as the
mechanism used to define the access table. It is therefore guaranteed
that the programmer will build a complete model of the application's
theoretical access table.
For the "code reuse" argument:
It is fine to consider the dispatch of the system call part of the OS,
or some other intermediate entity. I want the ACL itself (ie: the data
structure), and the check operation that is done on that ACL, to be
considered part of the "Object", unless it can be shown that both of
these have been generalized to the point where they are not tighly
coupled with the logic of the "Object", and could be applied to any
"Object". In my opinion, this generalization cannot be shown for the
In Hal's use of an ACL, the nature of the check is defined such that
its logic is tightly coupled with how the "Object" works. If you are
proposing a mechanism for removing this coupling of logic, then its
details are highly relevant to the "code reuse" argument. Please
> >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
> >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
I took your assertion that the MintMaker is about checks at the level
of "accounts", not pointers, to mean that you think of an "account" as
a coarser grain of access check than a pointer. I think of "pointer
grain" access control as access control on the level of individual
"Objects". Your assertion would only make sense in this view, if you
consider an "account" to be larger than an individual "Object". I
don't understand how an "account" could be considered larger than an
> >> 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.
And also if the concept necessarily requires certain failings in any
possible implementation. I think my "incomplete access table" argument
is such an argument.
> 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 think it would be good if we also had a DavidMint to work with.
Would you mind building one?
> 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 it looks like you are claiming an ACL design that would defeat both
of the arguments discussed in this email. I think we should flesh out
this design some more.