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

[Andy Lutomirski]

On Mon, Dec 10, 2012 at 7:47 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> Put an ACL on the program file.
> If you want different users to run with different privilege
> make two copies of the program and give them different
> ACLs and cap sets.
> If your program is so big that making a copy is a disk space issue
> it is too big to have privilege.
> If you can't deal with having the have different paths for different
> users write a shell script that redirects to the correct version
> based on user id.
>
> This is not rocket science. The kernel shouldn't be crammed
> with mechanism and complexity just because disto/"OS"/site
> developers can't be bothered with learning how the existing
> facilities work.

I agree.  But I think that the existing capability support is already
overcomplicated, and I'd rather make it simpler.  Sticking the
complexity in userspace is too difficult right now because it requires
fiddling with the file inheritable mask.

I think that the Windows approach is worth looking at.  See here:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa375202%28v=vs.85%29.aspx

In the Windows model, each capability ("privilege") can be in one of
three states: enabled (i.e working right now), permitted (i.e.
available upon request but not currently enabled), or removed
(disallowed to this process and all of its children).  Permitted
privileges are always inherited when a child process is created.

This is *way* simpler than Linux's model, and it works just fine*.

--Andy

* In fairness, MS apparently forgot to add the ability to drop
permitted privileges until XP SP 2 or thereabouts.  Adding it was a
no-brainer, though, because Windows has no concept of setuid, so
sendmail-style attacks are impossible even in principle.
--
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/