Casey Schaufler writes:
> Khimenko Victor wrote:
>
>> Huh.I can be wrong but why, oh WHY everyone is trying to add
>> low limits in design just to try to break then later ?
>> 32, 64 or 128 WILL NOT be enough in long run.
Correct... 512 ought to be enough for a very long time.
> Massive numbers of capabilities will make development and
> deployment of trusted applications difficult. The 44 capabilities
This isn't a problem caused by the number of capabilities.
Simply having to look up what capabilities do and think about
the issue is what makes development difficult. Once you have
more than one, you might as well have 1000.
If anything, the association of multiple abilities with a single
bit makes the system more difficult to comprehend. Going with one
ability per bit also eliminates the VERY hairy problem of splitting
capability bits.
> do. The value of capabilities is not in their granularity, but in
> the seperation of the uid from the ability to violate policy.
...
> Application policy enforcement is not well suited to capabilities.
You contradict yourself, perhaps because you do not want to deal
with the problem of allocating bits for userspace. If it is good
to separate UID from policy, then user-space code must be able to
do so.
> Capabilities are a kernel enforcement mecahanism, and adding things
> like a capability required to edit /etc/passwd just clutters it up.
> For that, I'd suggest a program list mechanism.
Ugh. It is not "edit /etc/password" (a specific file) but
"modify the user database" that is needed.
If the user database admin programs rely on UID, then we have not
left the UID-based system. THIS IS TOTALLY BROKEN. We might as well
just throw out all this complexity, since it isn't doing the job
it was intended to do -- it was supposed to end our use of UID as
a way to determine special ability.
UIDs and capability bits do not inherit in a compatible way.
It is insane to have two security systems that operate in
conflicting ways. I may want to use capability bits for security,
but how do I assign a bit for "database admin"? Without such
a bit, I am forced to use a per-UID system that does not have
compatible inheritance.
Really, it is better to reassign bits NOW than to do it later.
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:29 EST