Re: [RFC 3/3] ima: make the integrity inode cache per namespace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 30, 2021 at 06:55:51AM -0500, Stefan Berger wrote:
> 
> On 11/30/21 00:03, Serge E. 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.)
> > 
> > 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?
> 
> I cannot think of a scenario where a user wouldn't want/refuse to open a
> user namespace to get an IMA namespace...

The point is that unprivileged containers are still rare. And for quitea
few workloads they won't go away. Especially for a lot of Kubernetes
workloads - even if it finally has userns support - won't be able to
migrate to unprivileged. And I would think that they would want ima
support as well. But utlimately that's something the integrity folks
have to decide. If you decide that not having this feature for
non-CLONE_NEWUSER workloads then so be it.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux