Messages in this thread | | | Date | Mon, 17 Aug 2009 09:38:37 -0500 | Subject | Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance without disabling file caps | From | Will Drewry <> |
| |
Hi Andrew,
Cool, so yes, I would like for a parent process to be able to grant a subset of its privileges to its children.
I am interested in this approach for two reasons: 1. provides xattr-less filesystem SECURE_NOROOT 'support' 2. provides ephemeral capabilities
For #1, I concede that there are any number of workarounds to achieve xattr support on a given system. As with any workaround, they come with some overhead, be it in additional kernel support or in system management overhead. However, those can be dealt with at a non-kernel level for the most part.
For #2, it is currently the case that if a given user can run a binary with capabilities, they can always run it with those capabilities, just like a SUID binary. I would like support to empower a given process tree with a capability that is not granted unless that process tree has been traversed.
IMHO, a good example is /usr/bin/pulseaudio. On most distributions, it is a SUID binary, but it could probably get by with cap_sys_rawio+ep. However, even with 'setcap cap_sys_rawio+ep', it would still provide the attack platform used in several recent kernel NULL pointer dereferencing exploits. Any user that can normally execute pulseaudio can do so at anytime. However, it would be preferable if a user's pulseaudio sound server was run once with privilege (on X11 login, perhaps) instead of anytime during a given session.
It is almost possible to achieve #2 on existing systems, assuming xattr support can always be achieved. Step 1, setcap cap_sys_rawio+i /usr/bin/pulseaudio Step 2, pam_cap at X11 login to add cap_sys_rawio+i for a user session (alternately, use capsh). Step 3, run pulseaudio (pP' = (...) | (fI & pI) => cap_sys_rawio+ip)
It would mean that that specific user-session could launch pulseaudio with cap_sys_rawio+ip but not necessarily any active user with +x privileges on the pulseaudio binary. In addition, at any point in the session, cap_sys_rawio could be dropped permanently which would block future reuse/abuse (without relogin).
The problem with this approach is that many existing applications are capability-ignorant. Since the capabilities granted above would be in the inherited and permitted sets only, these legacy applications would still lack the privileges they need -- even if only because they are too dumb to fix it. To get the same effect, each of these daemons/packages/etc will need to be patched to attempt to setpcap any capabilities they might need to move them into the effective set.
My proposal would alleviate the need to independently patch existing code and would avoid filesystem-related workarounds. I'm looking at the change as a compatibility feature. root privileges could be parceled but still inherited - but only when the new securebit is set.
I hope that I'm making a bit more sense this go around. Sorry for any confusion.
thanks! will
On Sun, Aug 16, 2009 at 11:50 PM, Andrew G. Morgan<morgan@kernel.org> wrote: > Will, > > I've read this over a few times, but the in-lining is confusing me. > The idea of tying privilege only to 'anointed' binaries is the "POSIX" > capabilities model. > > If you are willing to concede that one can always arrange xattrs to be > convenient with various filesystem mounting techniques, are you saying > you would like all executables to be able to wield privilege if their > parent wants to give it to them? > > Thanks > > Andrew
| |