[E-Lang] Java 2 "Security" (was: Re:WelcomeChrisSkalkaandScottSmith
of Johns Hopkins)
Jonathan S. Shapiro
Mon, 29 Jan 2001 08:14:50 -0500
"Mark S. Miller" wrote:
> To me, if you add your delegate construct to an ACL system, the resulting
> system certainly can delegate (as that's the primitive you added), but it is
> no longer an ACL system.
I've been following this conversation only half-heartedly, because I
have nothing else to do and there aren't 90 students showing up in my
classroom in two hours, so I don't know how David proposed to add
"delegate" to an ACL system.
Setting aside the merits of ACLs, the addition of "delegate" within the
ACL model is quite easy. Split the own right into destroy and grant
authorities, and make grant transferable. For that matter, make destroy
transferable as well. This fits perfectly well within the ACL model (as
defined by Lampson), and it's a perfectly sensible resolution to the
I think that MarkM (and I) sometimes fall into the trap of arguing what
is bad about ACLs by arguing against the behavior of a particular
*implementation* of the model. The bottom line is that there exists no
reference implementation of ACLs. In fact, there exists (to my
knowledge), no implementation of ACLs anywhere, because the classic
access matrix model cannot be reduced to practice reasonably. In the
current conversation, I object strongly to the unification of users and
ACLs. It is completely and unequivocally wrong to make this unification.
The ACL model doesn't mention users ANYWHERE. [But yes, this is indeed
the most common implementation.]
Mark: please go reread the Lampson paper, as you have made this error
repeatedly and insistently. You are suffering from the disadvantage that
I taught this paper twice this semester. You really need to come do time
(er, um, *spend* time) in academia!
Lampson proposes triples of the form (subject, object, permissions) as
the underlying basis of the access matrix. In hindsight, this is a poor
formalism, because by "subject" Lampson specifically meant "process". A
better formalism would be
(domain, object, permissions)
where by "domain" we mean "protection domain". We then introduce some
form of equivalence class mapping from processes to domains, such as:
process/process (one process, one domain)
process/user (ACLs by user identity)
The nominal differences between ACLs and capabilities lie in two places:
1. Which way the table is factored (object centric vs. domain centric).
For understanding the respective power/weakness of the models this is a
complete non-issue. The factoring of the table is purely a matter of
storage and referential efficiency.
2. Which operations and commands (see Harrison, Ruzzo, and Ullman '74:
"Protection in Operating Systems") exist in the environment to update
The weakness in typical ACL implementations lies not per se in the "own"
right (which is NOT required by the ACL system and indeed may make no
sense at all depending on the equivalence class chosen for protection
domains), but in the choice of protection domains. This does NOT mean
that the ACL model is inherently flawed. It means that the equivalence
class in question weakens the protection model too badly. Secondarily,
the preconditions for updating the access table in the typical ACL
formulation are inadequate.
As to the rest, the choice of storage association is purely a matter of
which slicing operations you are trying to take.