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 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.
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.

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). I understand your concern about a relative performance impact with the 2 tree look up. We could, as a mitigation and if really necessary, add a shortcut/accelerator for flag references on the initial namespace (since it is never released AFAIK), so there would be no additional tree lookup on this namespace, which is probably the most common namespace.

We have a new version ready to post, now with a rbtree replacing a radix tree and following the solution #2 below.
I you agree, I can post this new version so we can discuss it further considering the overall solution.

Thanks.
--
Guilherme

-----Original Message-----
From: Mimi Zohar [mailto:zo...@li...] 
Sent: segunda-feira, 17 de julho de 2017 14:04
To: Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...>
Cc: lin...@li...
Subject: Re: [Linux-ima-devel] [RFC 2/4] ima: use namespaced flags for IMA_AUDITED on each namespace

On Mon, 2017-07-17 at 14:35 +0000, Magalhaes, Guilherme (Brazil R&DCL)
wrote:
> Mimi,
> Let me update you on the ideas below. First, on the 2-lookups 
> solution, we have one radix tree inside another. On the first radix 
> tree, the index is namespace id, which seems ok (not sparse). The 
> second radix tree is indexed by iint address, which must be replaced 
> by a rbtree as you indicated.
> The second point is about the possible alternative solution I 
> mentioned. Actually, I realized that we would have possible memory 
> leaks on that solution since it would not be possible to delete the 
> namespaced flags when a namespace is released. It would wait when the 
> namespace is reused for the same iint and then it would finally reset 
> the flags under that namespace. Then, the namespaced flags would never 
> be deleted (to avoid the need for locking the inode when the namespace 
> is released).
> 
> Therefore, we still have 2 options:
> 1) namespaced flags tree inside the iint structure, single lookup, but 
> when namespace is released it would have to lock and unlock each 
> related inode accessed under that namespace to safely delete the 
> namespaced flag. There can be hundred/thousands of iints namespaced 
> flags to delete.

Definitely not a good idea.

> 2) namespaced flags tree outside the iint structure, we would need 2 
> lookups when a namespace flag is referenced.

There needs to be two look ups, just not two tree look ups.

Mimi