[e-lang] Comments on securing_python.txt (was: Brett proposes object-capabilities for Python)

[Brett Cannon]

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
> >
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
> > 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
> systems
> (IBAC), such as the typical use of ACLs. And I like "what-I-have" security
> for
> authorization-based access control systems (ABAC), such as the typical use
> of
> object-capabilities.


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
> distinction,
> having to do with the form of access rights one is analyzing. Both
> who-I-am
> and what-I-have systems have both permission and authority, and both kinds
> of
> 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
such.

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.
> This
> 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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20060719/c1a9acb9/attachment.html