Messages in this thread | | | Date | Mon, 10 Dec 2012 11:13:32 -0800 | From | Casey Schaufler <> | Subject | Re: [RFC] Capabilities still can't be inherited by normal programs |
| |
On 12/10/2012 10:12 AM, Andy Lutomirski wrote: > On Mon, Dec 10, 2012 at 7:47 AM, Casey Schaufler <casey@schaufler-ca.com> 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),
Effective
> permitted (i.e. > available upon request but not currently enabled),
Permitted
> or removed > (disallowed to this process and all of its children).
~Inherited
> Permitted > privileges are always inherited when a child process is created. > > This is *way* simpler than Linux's model, and it works just fine*.
I see a different set of complications, and Windows never had a setuid bit to contend with. God created the universe in seven days, but then, He didn't have an installed base.
| |