Re: [Linux-ima-user] [RFC 04/11] ima: add support to namespace securityfs file

[Mimi Z. <zo...@li...>]

On Mon, 2017-05-29 at 20:34 +0000, Magalhaes, Guilherme (Brazil R&D-
CL) wrote:

<snip>

> >- IMA-audit:
> 
> >The IMA-audit messages can augment other file system security information 
> >used in security analytics/forensics.  This information should be on a per 
> >namespace basis, meaning that each time a new file is accessed/executed, 
> >there needs to be a separate audit message, even if a message already exists 
> >in another namespace.  Maintaining and cleaning up this per namespace cache 
> >information, allows development of the IMA namespace architecture 
> >independently of other issues.

> My understanding is that the Audit subsystem manages on its own, by using a 
> daemon per user namespace, the separation of messages per namespace. Audit 
> API (audit_log_start, audit_log_end, etc) clients, on its turn, must generate the 
> proper record and then use the Audit API to queue that record. What we did was 
> to add enough fields to the record to properly identify a pathname, considering 
> multiple mount namespaces. I thought this is what was missing on the IMA 
> perspective. Please clarify.

I'm referring to the IMA-audit messages that were introduced
in e7c568e0fd0c "ima: audit log hashes".  Appending the namespace
identification information to the existing information is not enough.
 The IMA-audit message needs to be generated the first time in each
namespace.  This requires storing the per namespace information
separately from the common information, for example the file hash.

The main difficulties are in how the common information vs. the per
namespace information are stored, referenced, and cleaned up.  Cleanup
will need to address when either the namespace itself or a dentry is
deleted.

All of the different IMA aspects require storing, on a per namespace
basis, IMA namespace specific information (eg. audit status within the
namespace, measurement status within the namespace, appraisal results
based on different policies/keys).

Once the architecture is defined, namespacing the other IMA aspects
should be straight forward.

Mimi