"Albert D. Cahalan" wrote:
>
> Casey Schaufler writes:
>
> ...
> > Be wary of adding capabilities. One vendor decided to use seperate
> > capabilities for each possible thing and ended up with 330!
>
> That system, with 330 capabilities, was more correctly designed.
It is my experiance, having worked with systems with capabilities
for some time now, that a granularity of hundreds of capabilities
can not possibily be said to be properly designed.
> Our system is broken.
Oh dear!
> We have no safe way to "split" a capability,
> so we are stuck with the existing granularity.
#define CAP_DAC_WRITE (0x01LL << 2)
#define CAP_DAC_READ_SEARCH (0x01LL << 3)
#define CAP_FOWNER (0x01LL << 4)
#define CAP_DAC_OVERRIDE (CAP_DAC_WRITE|CAP_DAC_READ_SEARCH|CAP_FOWNER)
is what we did in Irix when the POSIX draft changed. Although
I'd guess this isn't something you'd consider safe.
> Linux capabilities are kernel-only too, while a great deal of
> security is handled in daemons and set-uid programs.
Well you know, the kernel can only enforce it's own policies.
It's up to the security enforcing programs to, well, enforce policy.
> We might as well just rip out all this complexity, since it isn't
> doing enough to eliminate special UID values.
This same scheme (with file based capability sets, to be sure) works
just fine on the Trusted Irix product. No special privilege granted
by UID.
> For example, there
> isn't a "connect to X server" or "edit /etc/passwd" capability.
A common error in secure system design is to confuse a mechanism
with a policy. Folks often confuse ACLs with capability sets, for
example. The kernel (which enforces the file system access control
policy, which includes capabilities) doesn't know /etc/passwd from
/usr/people/casey/doom/btcat.wad, and shouldn't. If you want something
like that, you could implement an appropriate mechanism, such as
program access lists.
I would be very interested in seeing a write-up of your proposed
system security model. That would include the access policies
for all of the objects. Perhaps then I could see how it would all fit
together.
--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/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:06 EST