I understand.
>[snip]
>> >Please expand, I'm not following.
>>
>> >From your writing it appears that you're assuming that the Linux kernel
>> contains true capability support. Unfortunatelly, this is not so. The Linux
>> kernel contains support for capability lists, which is a different concept than
>> true (or pure) capabilities. Since most of the people refer to what is in the
>> kernel as 'capabilities', the confusion is inherent as newcomers who have read
>> about computer security get an impression that the kernel contains a powerful
>> token (aka key/lock aka descriptor aka true (pure) capability) based security
>> mechanism, when it really contains a fundamentally broken and abandoned (by the
>> people who put it together) concept of POSIX privileges (aka capability lists).
>
>I'm interested in why you think it's fundamentally broken. In the design
>issues I'm considering, it seems at _worst_ to be much better than the
>current root=all powerful model.
Well, to discuss brokeness of a concept, one would first have to pick a suitable
level at which to discuss it - is it the whole underlying concept (the concept
of capability lists) that is broken, or is it the specific design based on such
a concept (POSIX privileges, a specific capability list design) that is broken.
Whether POSIX privileges make any improvement or not over the current situation
is an issue in itself.
I will cover the first in a more theoretical manner as it is a concept that
we're talking about after all, and the second in a more practical manner. I
won't go into the last one.
As you are probably aware, there exist a number of design principles that the
designers of secure systems would be better off keeping in mind when designing
their systems. One of such principles is the principle of least authority. This
principle states that a program should only have the minimum authority that it
needs to get the job done. But in order to be able to really give the program
only the authority that it requires to get the job done, one must be able to
cut the total authority into arbitrarily small pieces. With capability lists,
one divides the total authority into smaller pieces by making a list of
privileged operations, turning specific privileges on and off as appropriate
for the program and attaching this list to the program in question. When the
program is run it can perform the privileged operations that were turned on in
its list of privileges.
The problem with this scheme is that one needs to attach the whole list of
privileges to each and every program, even though only one or two of the
privileges may be required by most of them. Since such a list takes up space,
and this space is multiplied by the number of programs in the system, there
cannot be an unlimited number of privileges in the list, forcing the designer
to choose between fine grain security and efficient use of space. Since each
capability in the list enables a single and specific privilege, one would,
conceptually, need an infinite list of capabilities to have arbitrarily fine
grain security which is needed to be able to really obey the principle of least
authority. That is of course not feasible in any real system.
One might want to circumvent the problem by not storing individual privileges
in an array but organizing them into a linked list instead, allowing one to
drop the disabled capabilities from the list and only keep the active ones.
With this strategy however one still faces the efficiency problem as the linked
list needs to be searched for any required capabilities, and it needs to be
searched every time the access control comes to play, which may with a longer
list and strict access control again result in substantial decrease in
efficiency of the system. The remedy is the same as before: a compromise
between security and efficiency, meaning you fail to obey the principle of
least authority again.
There are other important issues that designers who want to use capability
lists need to resolve, such as how to cut the total authority into individual
privileges for example. I would not like to dive deep into those issues though
as the inability to truly obey the principle of least authority, which is one
of the fundamental principles of security, is alone quite enough to consider
the concept at least as inadequate.
As for POSIX privileges, a specific design based on capability lists, it
contains a number of design failures besides the obvious disadvantages of
capability lists. For example, the POSIX privileges concept makes a distinction
between the permitted and the effective set of capabilities. In security
reality however, there is no 'permitted' set, only the set of effective
capabilities. When a capability is a single system call away (that can be taken
by the process anytime and from any point), marginal security gained by
'turning off' a capability in the 'effective' set but leaving it 'on' in the
'permitted' set is exactly zero, making the set of permitted capabilities
effectively the set of effective capabilities. In other words, your process is
either able to do something, or not able to do something - an extra syscall or
two makes no difference.
Furthermore, the POSIX privileges contain the third set of capabilities, the
inheritable set, which is also a design failure as it makes the design to fail
to contain the damage in case of a buggy privileged binary. Once a privileged
binary is broken into (for example at runtime by means of a stack overrun), it
can be made to spawn an arbitrary child (such as a shell for example) that will
inherit the authority of a buggy parent, thus enabling an attacker to gain
unauthorized access in a useful form (a shell for example). Because you never
know how the inherited authority will be used, inheriting authority in a
computer system is just as bad as when a stupid prince inherits the throne of
a great king.
There are probably many more issues about POSIX privileges, such as where to
store them, how to manage and delegate them etc that would require additional
attention, but I would not like to make this already long mail too long so I
will stop here. That the UNIX security tools and mechanisms often (and
sometimes completely) fail to obey other security principles, such as the
principle of psychological acceptability, the principle of economy of
mechanism, the principle of safe defaults etc is also beyond the scope of this
mail, but should nonetheless probably be mentioned anyway as they contribute
their share to the overall (in)security of the system and influence the
implementation of potential new security schemes.
>> As they say, the proof is in the pudding, so by all means, feel free to pursue
>> your implementation. Using capability lists is usually the last mistake that
>> people make when designing their security components, so I'd expect to have
>> this topic brought up relatively soon again.
>
>Well, I've got a bit of a learning curve ahead of me with kernel hacking;
>if for some reason you don't think the Linux implementation of capability
>lists will result in enormously improved security (when implemented and
>used properly), then it would be nice to know why _now_.
As I said above, I would not like to speculate whether POSIX privileges would
bring an improvement in security or not as that depends very much on the
implementation details. From a designer's point of view, they are inadequate
and broken and will in combination with existing subsystems lead to further
extensions and ad hoc solutions to solve the security problem.
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 Please read the FAQ at http://www.tux.org/lkml/