* Albert D. Cahalan said:
>
> Casey Schaufler writes:
>
> > Capability granularity is a touchy issue. What you're proposing is
> > having seperate capabilities for READ and WRITE access to a set
> ...
> > 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.
> Our system is broken. We have no safe way to "split" a capability,
> so we are stuck with the existing granularity.
Hmm... I don't think its broken, it's just not generic enough. If there was
a top-down design in a shape of a pyramid it would be more flexible. As it
is now, there are capabilities that are far too monolithic and cannot be
split just because they are one entitiy instead of a set of less capable
caps. Not to mention, that the linux-privs document documents several caps
that are not implemented in the kernel.
> Linux capabilities are kernel-only too, while a great deal of
> security is handled in daemons and set-uid programs.
That's ok, imho. Capabilities in the kernel protect the kernel and its data
structures, what's in the user space should rely on ACLs that co-exist with
the in-kernel caps.
> We might as well just rip out all this complexity, since it isn't
> doing enough to eliminate special UID values. For example, there
> isn't a "connect to X server" or "edit /etc/passwd" capability.
Hmm... these two aren't the kernel issue. For one, the "connect to X server"
isn't a general problem, but a specific one. You might demand the kernel to
have caps to restrict access to portmapper, smtp and whatnot. That's not the
kernel issue. As to /etc/passwd - it's not general as well. For kernel
/etc/passwd is just a file as thousands other files. If we had caps support
in the FS then you would fine-tune access to that file based on the
in-kernel caps, no need to provide any /etc/passwd - specific caps. Besides,
/etc/passwd is not the only form of the user database used - you can use the
NIS, LDAP, or GDBM databases - I'm sure you agree that having separate caps
for each of the cases wouldn't be a good idea... No, the access to the files
is user-space thing, and what I had in mind is protecting/giving access to
the in-kernel information.
marek
-
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:07 EST