Quoting Topi Miettinen (toiwo...@gmail.com): > On 06/21/16 15:45, Serge E. Hallyn wrote: > > Quoting Topi Miettinen (toiwo...@gmail.com): > >> On 06/19/16 20:01, se...@hallyn.com wrote: > >>> apologies for top posting, this phone doesn't support inline) > >>> > >>> Where are you preventing less privileged tasks from limiting the caps of > >>> a more privileged task? It looks like you are relying on the cgroupfs > >>> for that? > >> > >> I didn't think that aspect. Some of that could be dealt with by > >> preventing tasks which don't have CAP_SETPCAP to make other tasks join > >> or set the bounding set. One problem is that the privileges would not be > >> checked at cgroup.procs open(2) time but only when writing. In general, > >> less privileged tasks should not be able to gain new capabilities even > >> if they were somehow able to join the cgroup and also your case must be > >> addressed in full. > >> > >>> > >>> Overall I'm not a fan of this for several reasons. Can you tell us > >>> precisely what your use case is? > >> > >> There are two. > >> > >> 1. Capability use tracking at cgroup level. There is no way to know > >> which capabilities have been used and which could be trimmed. With > >> cgroup approach, we can also keep track of how subprocesses use > >> capabilities. Thus the administrator can quickly get a reasonable > >> estimate of a bounding set just by reading the capability.used file. > > > > So to estimate the privileges needed by an application? Note this > > could also be done with something like systemtap, but that's not as > > friendly of course. > > > > I've used systemtap to track how a single process uses capabilities, but > I can imagine that without the cgroup, using it to track several > subprocesses could be difficult. > > > Keeping the tracking part separate from enforcement might be worthwhile. > > If you wanted to push that part of the patchset, we could keep > > discussing the enforcement aspect separately. > > > > OK, I'll prepare the tracking part first.
Awesome - thanks!
