[cap-talk] ACLs: why not have them IN ADDITION to capabilities

Rob rmeijer at xs4all.nl
Tue Aug 1 01:40:37 EDT 2006


> Hence multiple security mechanisms should only be invoked as a desperate
> last resort. Sometimes such a desperate last resort is warranted. But I
> haven't yet seen a payoff to adding an acl system that comes close to
> warranting such an act of desperation. Your example below seems to be
> addressed appropriately simply by using logging forwarders. Logging
> forwarders don't tell you "who leaked", they tell you "who is
> responsible for the leak", which is actually the more important question
> to answer.
>
> --marcs

Combining capabilities with ACL actualy 'could' translate into a single
security paradigm that could be usefull in incident response.
I've done some attempts on this in the past, and the problem is
not that it would not be usable, or to complex, but that it would require
integration with the risk assesment side of security. You simply can not
configure such a 'full digraph authority' system by hand and keep things
managable by hand, you need to start of with an unidirectional
configuration, do a statefull risk assesment on that, and from the two
create the full-digraph version and don't again touch the resulting
configuration by hand. This means that if you need to make a change to the
original unidirectional configuration, you would again need to do a
statefull risk assesment. Given that good risk assesment people are
rather scarce and expensive, this ends up although conceptualy very
apealing to be an unrealistic aproach for the moment.
Maybe future advances in risk assesment could change this, but for the
moment I am afraid we are stuck with unidirectional single link access
controll.

Rob



More information about the cap-talk mailing list