Capability lists can be storage efficient, and in the case of a short
list they can also be efficient performance wise; but in the general
case, capability lists are inefficient because you have to scan the list
in order to extract an element and check it. But that is not the real
problem. With capability lists, the authority has to be partitioned such
that each capability fully and totaly covers a part of authority on the
system, but only this one specific part. There must be no overlapping of
authority that individual capabilities convey, because then there is a
possibility that you can do the same thing by invoking other
capabilities. If this rule is not obeyed, the object that will perform
an action if there is a specific capability in the list will have to
check for all combinations of capabilities that can produce the same
action. For example, if you have capabilities: read a byte, write a
byte, read a string, write a string; and you want to prevent
unauthorized objects from writing, the writer object will have to check
if the invoker has either 'write a byte' or 'write a string' capability,
which means that it already has to perform two checks to cover all
possible writing points. Such designs lead to utterly complex,
inefficient and buggy (and consequentially insecure) systems.
The only way to make sure that the above rule is obeyed is to make the
list short (no you cannot solve it by layering lists). But making the
list short will hardly enable building of objects that support the
principle of least authority, because - although partitioned - the
authority will still be given in relatively large chunks.
To summarize: if you have capability lists, you will either have a small
list or a complex system. If you have a small list, you won't have much
security because you don't support the principle of least authority. If
you have a complex system you won't have much security because you'll
have a lot of bugs.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu