Re: [Linux-ima-devel] [RFC 2/4] ima: use namespaced flags for IMA_AUDITED on each namespace

[Magalhaes, G. (B. R&D-CL) <gui...@hp...>]

Hi Mehmet,
How is going the work with this patch? Is there any open design decisions? 
I remember at least one which is about the creating a new IMA namespace. There are issues with this namespace creation once it depends on a mount namespace creation.
Could we create a new IMA namespace and set it to the current process through a user space request?

--
Guilherme

> -----Original Message-----
> From: Mehmet Kayaalp [mailto:mka...@li...]
> Sent: sexta-feira, 21 de julho de 2017 10:04
> To: Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...>
> Cc: Mimi Zohar <zo...@li...>; linux-ima-
> de...@li...
> Subject: Re: [Linux-ima-devel] [RFC 2/4] ima: use namespaced flags for
> IMA_AUDITED on each namespace
> 
> 
> > On Jul 19, 2017, at 4:09 PM, Magalhaes, Guilherme (Brazil R&D-CL)
> <gui...@hp...> wrote:
> >
> > Hi Mimi,
> > For all solutions with a single additional tree look up, the namespaced flags
> tree is placed inside the iint structure. This is what the POC posted by Mehmet
> does, and this mechanism is also the solution for 'namespacing' the
> integrity_iint_find() function.
> 
> See the patch set I posted yesterday [1], that does not place it inside the
> iint, and creates an rbtree as part of the namespace struct.
> 
> > However, this option suffers with the costly lock/unlock of hundreds of inodes
> when a namespace is released to cleanup namespaced flags, what makes this
> solution not acceptable for upstreaming as you indicated.
> 
> As a result, the namespace cleanup does not touch inodes or iints. However, we
> didn't save the inode-->namespace association, so we don't have a way of
> removing the flags when the inode is removed. But we keep a copy of ino and
> generation, so if inode matches but ino and generation do not match, we can
> reset and reuse it.
> 
> > We are really convinced that the solution #2 below is the best possible
> solution, which has 2 additional tree look ups for namespaced flags references
> (2 in addition to the existent iint tree look up, the first look up gets the list of
> flags for a given namespace and the second lookup get the target flag from the
> list for a given iint).
> 
> The extra lookup is the namespace one. We should be able to tell the current
> namespace without needing an rbtree or a hash table.
> 
> [1]: https://sourceforge.net/p/linux-ima/mailman/message/35956610/
> 
> Mehmet