On Mon, 2021-11-29 at 12:04 -0500, Stefan Berger wrote: > On 11/29/21 11:16, Christian Brauner 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 a constant and the keyring > IMA is using (and are held by the user namespace) is also constant > across setns()'s. Otherwise it is possible that the user could do > setns() to a different user namespace and be confused about the keys > IMA is using. So at least by piggy backing we have them together. The > aspect here may be 'usability'. > > I am somewhat sold on the USER namespace piggy backing thing... as > suggested by James. And to be clear, I don't think a separate IMA namespace is necessarily wrong a priori. However, all the original patch sets had the separate namespace approach and I worry that the keyring namespace in user namespace has forced our hand somewhat, so I wanted at least to post a semi-usable patch set showing what would happen if the IMA namespace were the user namespace for illustration so it would serve as a basis for discussion. James
