[cap-talk] "ACLs don't" paper rejected from Oakland 09

Matej Kosik kosik at fiit.stuba.sk
Mon Feb 2 05:06:25 CST 2009


Toby Murray wrote:
> On Mon, 2009-02-02 at 10:51 +0100, Matej Kosik wrote:
>> let us examine far
>> more important goal: how to follow principle of the least privilege? Is
>> this possible in ACL scheme? Can you provide some examples? Is there
>> anyone that claims it can be done? Can we see examples? Tanenbaum
>> himself and many people on this list can show that this is quite
>> straightforward if we use capabilities. Does anyone disagree with this
>> claim? Can we provide the supporting evidence?
> 
> Something that just crystalised for me was the following. Capabilities
> store permissions with the subject that uses them. ACLs store permission
> with the subject about whom they pertain. Storing permissions with the
> subject that uses them makes it easier to determine, then, whether those
> permissions match the function of the subject that is going to use them.
> It is easier to determine, then, whether that subject has excess
> permissions and, hence, if POLP is being followed.
> 
> Storing permissions with the subject about whom they pertain makes it
> easier to determine who has permission to access this subject in what
> way. Historically (and even presently) many see value in this from an
> audit perspective -- it's 'easy' to find out if someone can access this
> resource that shouldn't by examining its ACL. The prevalence of confused
> deputies in ACL systems undermines this audit argument, however. It is
> also clear that auditing POLA here is much more difficult. We can
> determine whether a particular subject has POLA enforced only by
> examining *every* ACL in the system. On the Internet, this is clearly
> impossible. Therefore, in general, POLA cannot be achieved in an ACL
> system (simply because doing the auditing is impractical if not
> impossible for real-world, large-scale systems). 
> 
> Is that fair? Has that been said before?

I am not expert concerning terminology but in these statements I would
continue the tradition to distinguish between the terms:
- subject
- object
Just to make them more readable to people who are used to that
distinction. But that is only nitpick less important to the message
itself. Otherwise I totally agree. I would even discriminated between:
- kernel-guarded capabilities
- language-guarded capabilities
Both have different properties. Kernel guarded capabilities can be
useful with arbitrary binaries but their finegrainness might be
inappropriately constraint by what kernel supports. Language-guarded
capabilities might provide finer-grained access control but at the
expense of constraining ourself to a specific language. Different levels
of security can be achieved by using one or the other variant.

The claim "ACLs and capabilities are somewhat equivalent" (this is not
what, by mistake or intentionally, Tanenbaum said) may be valid in
mainframe scope. If our goal is to insulate one user from the other, we
can choose either mechanism (OK--confused deputy disproves it but it is
so peculiar that people need not to get it immediately.) We can climb
either "ACL mountain" or the "Capability mountain". Regardless of our
decision, we can achieve "desired hight" (desired level of security). So
far the particular decision does not matter.

<CONTINUING SILLY FAIRYTALE>
However, if we consider mobile code (and today everything is mobile
code) then we realize that we must "climb higher". And this is where we
will find that while to certain degree we can also climb up on the ACL
mountain, it has finite height and we cannot go much higher without
returning to the "valey of insecurity" and starting to climb "mountain
of capabilities". Understandably, in reality that is not at all so
simple. We are not free to choose. To much investments where already
made to climbing "Mountain of ACL" and enabling others to climb it. So
final "logical" step is to build an SELinux/UAC "tower" there. Did we
reached desired hight? (Did we reached the desired level of security
from mobile code?) Some might choose to continue to live in delusion
that yes. Others returned back to the valey and started to climb a
different mountain. It may be frustrating relelation but should we
delude ourselves?
</CONTINUING SILLY FAIRYTALE>

> 
> Cheers
> 
> Toby
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 



More information about the cap-talk mailing list