>>> The header stuff can only *reduce* capabilities, other mechanisms such as
>>> suid-root or vfs cap support would be needed to raise caps.
>>> I don't think anyone would sell them as the *one* *true* answer.
>
> Ohh! So the kernel doesn't intend to support raising capabilities in the ELF
> header scenario? I see. So its not really a full principle of least
> privilege implementation.
Well, we get the same effect. We let setuid-root raise everything before
the header drops capabilities back down. This is just fine as long as you
don't let root log in.
>>> So worst case is they don't voluntarily lose some of the caps they would
>>> have gotten anyway.
>
>>> Right now setuid-root gives you everything, binary cap headers would allow
>>> you to trim that down.
>
> Yupp, but if they call other programs, then you have to kludge the disabling
> of privs so that the child process doesn't get any privileges.
This already works if you fix some of the nasty defaults and remove some
of the gross hackery in the exec code.
> This is how it works. A privileged process has priv a, b, and c in its
> effective set, inheritable and permitted sets. It execs another program
> that has none in its allowed set and none in its forced set (on the file).
> since the new processes effective, permitted and inheritable sets are
> determined by the intersection of the inheritable of the parent, and the
> allowed of the child (which is none) and the child process gets no
> effective, permitted, or allowed privileges.
Nope, the inheritable set does not get cleared.
>>>> in its effective capabilities set. Inode or namespace is fine and
>>>> dandy with me, as long as they don't get put into the CONTENTS
>>>> of the file ;-).
We need two things:
1. Place to store the data.
2. Indication that the data may be trusted.
Putting everying in the inode would work, but it breaks compatibility.
The namespace seems like a horrid place to store data or indicate trust.
Using ELF features as storage space:
a. setuid-root can provide trust
b. read-only media can provide trust
c. the immutable bit can provide trust
d. owned by UID 0 can provide trust (the root account might not exist)
...
> And because the kernel should restrict what processes can set privileges
> on files. If you do it as I mentioned above the kernel can keep ANY
> process from setting capabilities on a file, if that process doesn't
> have the "I can set file capabilities" capability.
This is the "trust" requirement. No problem, since there are many useful
ways to indicate trust. This can be considered a policy decision that
should be determined via mount options.
-
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/