> Please, don't play invalidation games with me.
Allow me to offer humble apologies. I meant no disrespect.
My only desire was to share the results of my experiance with
the topic.
> 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.
Had you presented a frivolous, obvious, or stupid case no one,
myself included, would have said a word.
> That *all* of the replies that I received (including
> yours), together with the on-going discussions that try to circumvent various
> implementation problems
Well, we are trying to get something working here, and there is
a bit of baggage to be dealt with.
> (for which you claim to be nonexistant),
Nah, the problems are there, and are very real. They are not
insoluable, however.
> 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.
I'm not the sort to believe things without proof. That these problems
can be resolved has several existance proofs, so I'm satisfied.
> So I'll go back to my studies and you can continue with your implementation.
I, for one, will miss you if you do. If everyone agreed with me
the securitt world would be in a really sorry state.
> This way we may both learn some more.
Ah, hang around. I'm sure that alot of people learned a whole
lot about policy issues as a result of your arguments.
> [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.
Certainly there's a component of pragmatic efficiency in having a
smaller number of capabilities, but that is far from the most
important issue. Usability is an important factor. Ever wonder
why people get upset when you say you're going to enhance their
system by taking away the Superuser? Programming securely on a
system with 40 capabilities is stressfull enough, my little brain
boggles at the notion of 330.
My argument is more to the tune that a fine grain of security policy
does not necessarily require a fine grain of capability.
> [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.
This would seem obvious. What am I missing?
> [3] In other words, if your security model sucks, you don't need fine grain
> security.
Ah. Well, if your security model sucks, a fine grain implementation
of it is going to really really suck, and the attempt at granularity
is going to make the fact obvious to the most casual observer.
> If you don't have fine grain security, your security model will suck.
This has not been my personal experiance. For the Trusted Irix
evaluation we produced a dandy model whilst retaining the Superuser.
Granularity and suckiness are independent attributes of a security
model.
--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/