"Albert D. Cahalan" wrote:
> 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.
Let me take a deep breath, and a step back. I'm assuming that
a capability is the permission to violate a system policy. The
granularity described in the posix draft (which DG objected to)
assumes that all instances of enforcing a policy would use the
same capability. A developer who is sufficiently familiar with
the system policies ought to have little trouble determining
what capabilities to use in any given situation.
If your system security policy is reasonably small it follows
that the number of policies available to violate will be small
as well. Hence, the number of capabilities will also be small.
It is my position that you can use the logic in reverse. If you
have a large numbers of capabilities that implies a large number
of policies available to violate, which is in turn indicative
of an unreasonably large system security policy.
> If anything, the association of multiple abilities with a single
> bit makes the system more difficult to comprehend.
This is true only if you don't understand the system security policy.
> Going with one
> ability per bit also eliminates the VERY hairy problem of splitting
> capability bits.
Which you don't have to do if the initial assignment is done with
the policy in mind. Splitting capability bits ought to be a rare
occurance which accompanys a change in the policy. There will be
some, but the ability to do so ought not be a design criteria.
>
> > 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.
If I appear to contradict myself I humbly appologise, and offer
clarification.
The kernel uses capabilities to identify processes which are allowed
to violate its policies. Any policies which are enforced outside of
the kernel (e.g. permitted to modify entries in /etc/passwd other
than the entry associated with the invoker) can not be enforced by
the capability mechanism. There is no way for the capability mechanism
to prevent ed(1) from violating this policy. Thus, it is inappropriate
to count on capabilities to enforce, or even be involved in the
enforcement of, that policy. Capabilities in user space are advisory
at best.
> > 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.
That's more like it. You've recognized the difference between a
capability which identifies a policy and a capability which is
associated with a particular action. Now what you need is a description
of all the ways in which any component of the "user database"
can be modified. Once you have that, you're on the way to defining
the policy on the application object which is the "user database".
Once you have those, you can identify a reasonable mechanism to
enforce that policy. My quarter says that capabilities are not that
mechanism.
> If the user database admin programs rely on UID, then we have not
> left the UID-based system.
The descretionary access control policy and capability policy will
always have to be used together to enforce the system security policy.
> THIS IS TOTALLY BROKEN.
Naw, it's a matter of keeping the totallity of system security policy
and mechanism in mind when designing and implementing system utilities.
> 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.
I don't think that anyone said that would happen overnight. It
won't. Our experiance with capabilities in Irix is that the change
from SuperUser to Capabilities will be slow and deliberate. The
change requires experiance with the scheme that just isn't there yet.
> UIDs and capability bits do not inherit in a compatible way.
Do you mean today, or in the posix scheme? In either case I
suggest that your assertion is unfounded.
> It is insane to have two security systems that operate in
> conflicting ways.
OKay, so? Are you claiming that there is a conflict between the
Linux descretionary access control policy and the capability policy?
What is the conflict?
> I may want to use capability bits for security,
> but how do I assign a bit for "database admin"?
You wouldn't. You're confusing a privilege based scheme, which
capabilities are, with a role based scheme, which capabilities
are not. Capabilities can be helpful when implementing a role scheme
but they are not sufficient by themselves. This is a common error.
> Without such
> a bit, I am forced to use a per-UID system that does not have
> compatible inheritance.
It is important to consider all of the system security policies
and mechanisms when implementing utilities.
> Really, it is better to reassign bits NOW than to do it later.
It is best to define a policy now, and ensure that the capabilities
are appropriate to that policy now.
--Casey Schaufler Manager, Trust Technology, SGI casey@sgi.com voice: (650) 933-1634
- 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 : Wed Feb 23 2000 - 21:00:15 EST