Richard Guy Briggs <rgb@xxxxxxxxxx> writes: > On 2019-07-16 19:30, Paul Moore wrote: >> On Tue, Jul 16, 2019 at 6:03 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: >> > On 2019-07-15 17:04, Paul Moore wrote: >> > > On Mon, Jul 8, 2019 at 2:06 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: >> >> > > > At this point I would say we are at an impasse unless we trust >> > > > ns_capable() or we implement audit namespaces. >> > > >> > > I'm not sure how we can trust ns_capable(), but if you can think of a >> > > way I would love to hear it. I'm also not sure how namespacing audit >> > > is helpful (see my above comments), but if you think it is please >> > > explain. >> > >> > So if we are not namespacing, why do we not trust capabilities? >> >> We can trust capable(CAP_AUDIT_CONTROL) for enforcing audit container >> ID policy, we can not trust ns_capable(CAP_AUDIT_CONTROL). > > Ok. So does a process in a non-init user namespace have two (or more) > sets of capabilities stored in creds, one in the init_user_ns, and one > in current_user_ns? Or does it get stripped of all its capabilities in > init_user_ns once it has its own set in current_user_ns? If the former, > then we can use capable(). If the latter, we need another mechanism, as > you have suggested might be needed. The latter. There is only one set of capabilities and it is in the processes current user namespace. Eric
