> 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.
Worrying over space required to maintain capability sets is silly.
At 24 bytes a pop (on Irix) that just isn't an issue.
The choice of capability granularity is a sigificant issue. On
Irix there are about 40. On DG/UX there are 330. Me, I prefer a
set that I can deal with.
> 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
This will depend on how you choose to map your capabilities to
your security policy. For example, you could choose to map
stime(2) and adjtime(2) to a single capability or give each
their own. On Irix, capabilities are mapped to the policy
(e.g. MAC, DAC) enforced, without regard to the type of object
(e.g. file, message queue). On Trusted Solaris I've been told
(I'm not 100% sure I have this right) they have a seperate
capability for each (e.g. file MAC, message queue DAC). In any case,
the granularity of capability ought to reflect the system security
policy in some coherant way.
> That is of course not feasible in any real system.
It's not so much that it's infeasible as it's unnecessary
and misses a significant point WRT system security policy,
which is that there ought to some reason to it.
> 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.
To date bitmasks have proven sufficient.
> 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.
This has not proven to be a problem in real implementations.
> 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.
Again, this is strait forward, if not simple or painless.
One decides the capabilities based on:
1. Desired system security policy
2. Where you have calls to suser() in the kernel.
2a. Where you have those Baaaaad euid == 0 checks.
> 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.
I don't believe that you've made a compelling case for
the disadvantages of capability lists, as noted above.
> 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.
In this, we disagree. In a world where all programs are coded
correctly (see TCSEC A1 requirements) you might have a point.
However, even good programs somethimes do things they oughtn't.
The principle of least privilege has a time axis; there is a
very real distinction between having a gun and having a loaded
gun.
> 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.
The purpose of the inheritable bits is to allow a program to be
set up so that it can NOT have a capability (by leaving it out
of the inheritable set on the binary).
> There are probably many more issues about POSIX privileges, such as where to
> store them, how to manage and delegate them etc
There are several ways to store them, many of which have been
discussed (at length!) here. Manageing and delegating them
are easy.
> 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.
Having been involved in the design of the POSIX capabilities,
and having implemented them on a real commercial system, I believe
your stated opinions to be unfounded. I believe that I have
sufficient evidence to refute the bulk of your claims, and that
many of your assertions are based on insuffient information.
In short, POSIX capabilities are completely implementable.
--Casey Schaufler voice: (650) 933-1634 casey@sgi.com fax: (650) 933-0170
- 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/