[e-lang] Comments on securing_python.txt (was: Brett proposes object-capabilities for Python)
brett at python.org
Thu Jul 20 02:03:53 EDT 2006
On 7/19/06, Mark S. Miller <markm at cs.jhu.edu> wrote:
> Brett Cannon wrote:
> > The new doc is named securing_python.txt and
> > can be
> > found through the svn web interface at
> > If people have questions feel free to ask here or me personally.
> A first quick comment on your doc:
> > There are essentially two types of security: who-I-am
> > (permissions-based) security and what-I-have (authority-based)
> > security.
> I think this mixes up two distinctions.
> I like your term "who-I-am security" for identity-based access control
> (IBAC), such as the typical use of ACLs. And I like "what-I-have" security
> authorization-based access control systems (ABAC), such as the typical use
Thanks. I also tweaked the wording based on an email from Alan to denote
that what-I-have security is more of a super-set of object-capabilities.
However, "permission" vs "authority" labels a largely orthogonal
> having to do with the form of access rights one is analyzing. Both
> and what-I-have systems have both permission and authority, and both kinds
> systems should be analyzed in terms of both forms of access rights.
Fair enough. But there is a reason I didn't make the permission/authority
distinction a key facet in the whole who-I-am/what-I-have comparison. I
want to make the distinction blatent so as to be able to explain to people
on python-dev how you can take an approach different from using ACLs and
In the Caretaker example in my talk, Bob has permission to access the
> caretaker, and (until Alice revokes) authority to access Carol. In an
> object-capability system, a capability itself is a permission. Likewise,
> in an
> ACL system, an ACL entry is a permission. Permission says what actions the
> participants can directly cause. To analyze what constraints any security
> arrangement imposes on what its participants can actually *do*, i.e., what
> *effects* their permitted actions can cause, one must analyze authority.
> is true of both IBAC and ABAC systems.
I will have to wait until I get into the office tomorrow, but I will
double-check I am not mixing up authority and permission (only thing I can
think of off the top of my head is mentioning POLA) and maybe try to work
in permission/authority into it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the e-lang