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

Thanks, Mehmet.

> 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.
Does it also solves the file change case? Should you add the i_version? When a file is changed, the namespaced flags must be cleared in all namespaces so the file can be audited again in all namespaces. The i_version/generation checkings should be done every time the namespaced flags are referenced and also clearing the flags if not matching, right?
On the other hand, all these new fields consume memory which might be a considerable amount when there are many files under many namespaces.

> The extra lookup is the namespace one. We should be able to tell the 
> current namespace without needing an rbtree or a hash table.
This is a good way to avoid the need for additional 2-look ups, while it is still not clear to me why a whole new namespace is needed and we should think about it carefully to avoid side effects. It seems actually an extension of mount namespace, it is like this probably related to possibilities of upstream acceptance. I believe AppArmor tried to add a real new namespace with a new clone() flag and it was not accepted. Any concerns with that? This new IMA namespace could be used in the future for namespacing the policy, while I believe the user namespace could be a better option for namespacing the policy.

--
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...>; lin...@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