On Mon, Nov 29, 2021 at 11:03:17PM -0600, Serge Hallyn wrote: > On Mon, Nov 29, 2021 at 12:04:29PM -0500, Stefan Berger wrote: > > > > On 11/29/21 11:16, Christian Brauner wrote: > > > On Mon, Nov 29, 2021 at 09:35:39AM -0600, Serge Hallyn wrote: > > > > On Mon, Nov 29, 2021 at 09:46:55AM -0500, James Bottomley wrote: > > > > > On Mon, 2021-11-29 at 15:22 +0100, Christian Brauner wrote: > > > > > > On Mon, Nov 29, 2021 at 09:10:29AM -0500, James Bottomley wrote: > > > > > > > > > I kept thinking about this question while I was out running and while I > > > admittedly have reacted poorly to CLONE_NEWIMA patches before it feels > > > to me that this is the right approach after all. Making it part of > > > userns at least in this form isn't clean. > > > > > > I think attaching a uuid to a userns alone for the sake of IMA is wrong. > > > Additionally, I think a uuid only for the userns is too limited. This is > > > similar to the problem of the audit container id. If we have some sort > > > of uuid for ima it will automatically evolve into something like a > > > container id (I'm not even arguing that this is necessarily wrong.). > > > We also have the issue that we then have the container audit id thing - > > > if this ever lands and the ima userns uuid. All that makes it quite > > > messy. > > > > > > I think CLONE_NEWIMA is ultimately nicer and allows the implementation > > > to be decoupled from the userns and self-contained as possible. This > > > also means that ima ns works for privileged containers which sure is a > > > valid use-case. > > > > The thing is that piggy backing on the user namespace at least allows us to > > 'always see' where IMA's keyring is (across setns()). If we were using an > > independent IMA namespace how would we guarantee that the user sees the > > keyring for IMA appraisal? We would at least have to take a reference (as in > > get_user_ns()) to the user namespace when the IMA namespace is created so > > that it at least the association of IMA namespace to user namespace remains > > Maybe we pull they keyring info into a new struct which is referred > to and pinned by both user_ns and ima_ns? (But I actually am ignorant > of how ima is using the keyrings, so again I need to go do some reading.) That's one way of doing it and we'd be able to shrink struct user_namespace because of it if we have to go down that road anyway. > > More moving parts isn't my first choice. But if you need namespaced IMA > for containers that aren't doing CLONE_NEWUSER, then a separate ima_ns is > your only option. Is that a requirement for you?
