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

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

Hi Mimi,
Thanks for the further explanations.
We now started to work on a solution for namespacing the IMA-audit as you indicated as a first step and still aiming a bottom-up design from this point to other IMA areas.
Talk to you soon.

--
Guilherme

-----Original Message-----
From: Mimi Zohar [mailto:zo...@li...] 
Sent: segunda-feira, 29 de maio de 2017 23:27
To: Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...>; John Johansen <joh...@ca...>; dmi...@gm...
Cc: lin...@li...; lin...@li...; ty...@do...; Souza, Joaquim (Brazil R&D-ECL) <joa...@hp...>; Edwards, Nigel <nig...@hp...>
Subject: Re: [RFC 04/11] ima: add support to namespace securityfs file

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