> The important thing about the
>granularity of capabilities is that it allow privilege (note
>the use of the P word) to be allocated to a degree which is
>consistant with the system's security model.
[3]
> One reason why Unix
>based systems have struggled against the B2 criteria is that
>the Unix security model includes a binding between user ID, which
>is a DAC concept, and the capability to override policy. Once the
>user ID and capability to override policy are decoupled it
>becomes necessary to decide how to map the new capability policy
>to the implementation.
[2]
> There are several factors which infleuence
>the mapping, including level of assurance desired, how close the
>code is to being done, how complex the security model is, and
>what capability list representation has been chosen. I personally
>think that the largest single factor is backword compatability.
>Large numbers of capabilities, especially those designated for
>applications, require more work in applications than fewer.
[1]
>Hence the brewhaha. The classic arguement goes like this:
>
> "The model says ...."
> "But the code says ...."
> "Fix the code!"
> "Fix the model!"
>
>Repeat as necessary.
Please, don't play invalidation games with me. I presented a case for a
serious reconsideration of the security model used in Linux, based on
inadequacy (feel free to consider it as only perceived by me as such; your
opinion may differ) of the capability lists to support a number of fundamental
security principles. That *all* of the replies that I received (including
yours), together with the on-going discussions that try to circumvent various
implementation problems (for which you claim to be nonexistant), merely
confirmed my claims (even though probably some or many of the respected authors
of those mails would not agree with me on that; YMMV) is an issue in itself,
but as they say, one who believes needs no proof, one who doesn't can't be
proven to.
So I'll go back to my studies and you can continue with your implementation.
This way we may both learn some more.
Andrej
[1] In other words, because of <your random capability list deficiency of the
day here>, you need to make a compromise between a large number of capabilities
(that is, fine grain security) and <your random form of efficiency here>. See 2
for results.
[2] In other words, you need to decide how you're going to cut total authority
into individual privileges in the capability list. See 1 for reason.
[3] In other words, if your security model sucks, you don't need fine grain
security. If you don't have fine grain security, your security model will suck.
-- 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/