On Mon, Dec 10, 2012 at 7:47 AM, Casey Schaufler <ca...@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), 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
