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

[lists at notatla.org.uk]

Tyler Close <tyler.close at gmail.com> wrote:

> writing a paper to clearly explain to the world why ACLs, and derived
> works, cannot possibly work for access control in multi-user systems

I don't know that much about academic publishing but here are some
thoughts that might make these arguments more acceptable to mainstream
security techies.

ACLs are a limitation imposed on a permit-all environment and so less
likely to implement POLA than a system that provides authority explicitly.
  http://www.ranum.com/security/computer_security/editorials/dumb/index.html
AIUI you are aiming to show that even for cases where the authority is supposed
to be the same there are realistic conditions when they aren't (and can't be).

A large section early in the paper works on the user-vendor-compiler
problem which assumes authority different from current OS designs (as
you admit in footnote 2).  This makes it easy to dismiss that section
as irrelevant - the user chose to trust the compiler.

In 2.3 you point out that the ACL and capability approaches evaluate the
permissions at different times and that is involved in how they get different
results.  (This is the first time I recall seeing that explicity stated.)
That observation together with the way caps combine naming with authority gives
us a way to tackle a different confused deputy:
 [root's cron]    find /tmp -type f -mtime +7 -exec rm {} \;
where I'm viewing rm as the deputy and the multiparty aspect comes from all
users being able to write to /tmp.

I often see commands like that in root's cron.  It's been known for
years.  The webserver shows this file as last modified in 1996.
    http://www.outpost9.com/exploits/cronTabNoNo.txt
In fact when this came up at work last year someone said this is years old -
hasn't it been fixed yet?  (Some people don't know a minor implementation bug
from a long-term design flaw.)

There are several programs that work fairly hard at solving this within the Unix
idiom but they all create an intent to remove a file of a certain name before
arranging to remove it by name.  A cap approach where find would pass to rm a
reference to the same thing it checked would remove the race condition as well as
doubt about where the authority came from.

That illustrates the non-equivalence.  If the storage workers here can show that
their systems can do the right thing that would add to the demonstrative power.


Schneier says:
 That's an important lesson. Identity theft solutions focus
 much too much on authenticating the person. Whether it's
 two-factor authentication, ID cards, biometrics, or whatever,
 there's a widespread myth that authenticating the person is
 the way to prevent these crimes. But once you understand that
 the problem is fraudulent transactions, you quickly realize
 that authenticating the person isn't the way to proceed.
    http://www.schneier.com/blog/archives/2005/04/mitigating_iden.html