[cap-talk] non-coherent caches of security policy (was: Capabilities and ACLs in Spring?)

[Eric Northup]

On Sunday, April 06, 2008, 2:38 AM, Mark Miller wrote:

[... Venkatesh asks about Spring ...]

Welcome to cap-talk, Venkatesh! :-)

> IIRC, Spring only had ephemeral capabilities, much like Unix has
> ephemeral file descriptors. They were thought of only as a way to
> efficiently cache ACL-based decisions. In any case, the only
> persistent representation of permissions were ACLs. As caches, both
> Spring caps and Unix file descriptors are unsafe -- they are not
> invalidated by ACL updates. Therefore, had the system gotten more
> reliable, it would have become less secure.

Is anyone aware of documentation or analysis of the vulnerabilities
introduced by the non-coherence of refcounting (as opposed to prompt
invalidation) as security policies change?

It strikes me as a simpler version of the same problem that SELinux
has where the system must be rebooted (in the general case) after a
policy update (because, even if the new policy would have allowed the
system reference graph to evolve to its current state, it might have
used different taint labels).

My recollection is that the various versions of *NIX which were
customized for multilevel security environments gained the ability to
invalidate open file descriptors to preserve coherency.  But I wasn't
able to find any discussion of threat models or attack scenarios.

I can imagine ways to attack such systems, but it would be nice if I
could point people at an existing description of the problem.

-Eric