[cap-talk] "ACLs don't" paper rejected from Oakland 09
Matej Kosik
kosik at fiit.stuba.sk
Mon Feb 2 03:51:53 CST 2009
Hi Tyler,
Tyler Close wrote:
> Hi all,
>
> This past fall, in the wake of the clickjacking news, I set about
> writing a paper to clearly explain to the world why ACLs, and derived
> works, cannot possibly work for access control in multi-user systems
> like the Web. I thought I did a pretty good job, and so submitted it
> to the Oakland security conference. Unfortunately, I was unable to get
> my point across to the reviewers. I thought a coherent argument
> explaining why ACLs don't actually do any of the things they are
> commonly believed to do would be an important contribution. AFAICT,
> the reviewers believe the ACL model has already fallen into complete
> disrepute, but simultaneously don't seem to quite get it. Other
> reviewers seem to have missed sections of the paper where I thought I
> clearly answered questions they seem to still have.
>
> I've put the oakland09 submission, rejection email, and my updated
> version of the paper at:
>
> http://waterken.sourceforge.net/aclsdont/
>
> I'm feeling demoralized now.
I hope that you will have more luck elsewhere.
> Constructive criticism and productive
> next steps appreciated.
>
> --Tyler
Yesterday I read related sections in the Minix book:
- 5.4 Security
- 5.5 Protection Mechanisms
Section "5.4.3 Design Principles for Security" says:
"Fourth, give each process the least privilege possible. If an editor
has only the authority to access the file to be edited (specified when
the editor is invoked), editors with Trojan horses will not be able to
do much damage. This principle implies a fine-grained protection scheme.
We will discuss such schemes later in this chapter."
I thought: 'Wow, how he will propose we should do that?"
Reading through sections 5.4 and 5.5 there is only one paragraph that
indicates what to do (at the end of section 5.5):
"On the other hand, capabilities solve the problem of sandboxing mobile
code very elegantly. When a foreign program is started, it is given a
capability list containing only those capabilities that the machine
owner wants to give it, such as the ability to write on the screen and
the ability to read and write files in one scratch directory just
created for it. If the mobile code is put into its own process with only
these limited capabilities, it will not be able to access any other
system resources and thus be effectively confined to a sandbox without
the need to modify its code or run it interpretively. Running code with
as few access rights as possible is known as the *principle of least
privilege* and is a powerful guideline for producing secure systems"
He does not explain how to do a similar (quite important) thing with
ACLs. Was that already achieved? Is that planned? Is UAC the solution?
Is SELinux the solution?
Despite showing different qualities of ACLs and capabilities, he concludes:
"Briefly summarized, ACLs and capabilities have *somewhat complementary*
properties."
He said "somewhat complementary" as opposed to "somewhat equivalent".
This term is imprecise and deserves more concrete examples. Most of us
are concerned with POLA (or POLP). While ACL might provide better
mechanisms for:
- revocation of permission
- ensuring non-delegation of authority
(Capability Myths demolished already address those) 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?
While the ability to insulate one user from the other might have been
very relevant in mainframe era, currently most of us should be concerned
with POLA.
If we compare ACLs to faceted eye of a bee
and capabilities to the eye we ourselves use
these two organs also serve *somewhat the same goal*. There are many
ways in which one as well as the other organ could be improved by
evolution. But on the evolution landscape, they are on *completely
different "mountains"*. By evolution one cannot evolve into the other.
It would mean going downwards towards valley of blindness and this is
not what happens by evolution.
Concerning the unfortunate matrix he says:
"*Conceptually, at least* one can envision a large matrix, with rows
being domains and the columns being objects."
I read that he does not say that this is the ultimate viewpoint. Only
the first approximation. Which may be fine.
I am not very much familiar with web technologies, so I can't comment on
the clickjacking problems. Random (maybe useless) links:
http://www.hackszine.com/blog/archive/2009/01/clickjacking_twitter.html
There are also many other situations where ACLs fail and people still
rely on them. I regard these efforts that they are not completely serious.
Regards,
--
mk
More information about the cap-talk
mailing list