Re: [RFC] Capabilities still can't be inherited by normal programs

[Andy Lutomirski]

On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote:
> There is a fairly well written paper ;-) explaining how things are
> supposed to work:
>
>   http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf
>
> The inheritable set is not intended to work the way you seem to want.
> Naive inheritance like that is quite explicitly the opposite of what
> was designed.

I'm aware that the system was designed, or perhaps evolved, to prevent
users with uid != 0 from inheriting capabilities unless vfs
inheritable caps are granted on a per-file basis.  I want a way around
that -- I want to mix non-root, capabilities, and exec.  This is damn
near impossible right now if I don't have CAP_SETFCAP or root's
explicit, per-program cooperation.  CAP_SETFCAP is essentially
equivalent to "let me do anything".

As it stands, using something like pam_cap to grant a user cap_net_raw
is useless -- that user can't use the privilege because (unless uid ==
0) the privilege will never end up in the permitted set.

I want to come up with a way to change this that will, convincingly,
not open up any new security holes.  The current concept of process
inheritable capabilities seems so vague and so oddly defined that I'm
not sure I want to touch it.  In an ideal world, I'd want pI <= pP and
fP <= fI to be invariants, and I'd like programs without vfs caps set
to have fI = <everything>.  Making this change will surely break
something, though.

I'm looking for ideas.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/