Marek Habersack writes:
> * 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.
Huh? How would you split "foobar" without breaking existing systems?
>> 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.
[please read to the end where I complete my explanation]
Nope, this doesn't work. ACLs are tied to UID and are inherited
through the filesystem structure. Capabilities are tied to processes
and are inherited as processes are created. This is very different.
I don't want to let users edit a specific file with user data.
I want to let privileged code verify that a process has the right
to perform restricted actions. The kernel (one chunk of privileged
code) can check for the right to "chown" (one restricted action).
The kernel is not the only privileged code.
So we have one security mechanism for operations that are defined
solely by the kernel, and no good mechanism for those that are not.
>> 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.
Only the kernel can provide correct security inheritance.
The kernel need not actually interpret the bits; they may
instead be defined by the Linux Standard Base or whatever.
This is a very ugly problem; we should not deny it exists.
We need a "capability bit registrar" to allocate the bits.
(just as we need registrars for device numbers, system calls,
a.out library address space, MIME types, etc.)
> For one, the "connect to X server" isn't a general problem,
> but a specific one.
All of the capability bits address specific problems. :-)
> You might demand the kernel to have caps to restrict access
> to portmapper, smtp and whatnot. That's not the kernel issue.
You seem to prefer minimal design over correctness. There is no
way that userspace can provide access control inheritance of the
type offered by capability bits.
> 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.
That is half of an answer: the DG-UX OS can deny file access to
every process lacking a file-specific capability.
> 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...
Of course I agree. One may reserve a single capability bit for
the "modify user database" concept, and /bin/chfn may check it.
This is exactly what DG-UX does -- helping to earn a B2/B3 rating.
> 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.
The whole "in-kernel" distinction is flawed.
With the old system, the kernel would check UID and GID.
With the old system, user-space would check UID and GID.
With the new system, the kernel checks capability bits.
With the new system, user-space... ARRRGH!!!!!
I hope you can see this now. User-space must be able to support
security that is compatible with what the kernel uses. If all
the user-space code must keep using UID and GID, then we are
still suffering from the "privileged UID" problem. We might as
well throw out capabilities then, since they aren't solving the
problem they were designed to solve.
-
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:09 EST