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

> (Wow, you should did Cc a lot of people.)
Reducing the list for now.

>I'm really sorry Guileherme, but as I previously explained, IMA has 
>many aspects to it - the original file measurements (IMA-measurement), 
>file hash/signature appraisal (IMA-appraisal), and file audit messages
>(IMA-audit) used for security analytics/forensics, not the file system 
>auditing.  To namespace IMA properly requires addressing some 
>underlying problems - >securityfs, root privilege required for writing 
>security xattrs, per namespace IMA keyring - to name a few.
We really considered all these aspects and they are either already addressed 
on this patch series or planed as future work items. That means we already 
have in plans incremental changes without compromising our basic design. 
We should have sent a summary of the design assumptions before hand,
sorry. So, let me take this opportunity to present some of them. I believe 
we should have a brief phone conference to clarify the plan and make sure we 
are all on the same page.

>- IMA-measurements:
>
>The namespacing design will need to support different types of environments. 
> For example, depending on the environment, namespaces can come and go 
>frequently. In such an environment do we really want all the namespace 
>measurements to be included in the system measurement list, or should each 
>namespace have its own measurement list?  
As a first step, we suggest a single measurement list for the entire system. The 
reason is what remote attestation requires. We would need a solution for the 
small number of TPM PCR limitation. The vTPM is not a simple solution and 
would need some effort on its own to be integrated with containers. Basically, 
we would need to adapt vTPM from VMs to the containers reality, maybe 
protecting the software stack with Intel SGX or other similar technology. So, 
we considered again this is a future work item and still possible to evolve from 
our first implementation.

>Should the namespace measurement policy be the same as the system 
>measurement policy?  Should the namespace (container) owner be allowed to 
>modify their own policy?  If a file matches a rule in both the namespace and 
>system policies, should the file measurement be in both the namespace and the 
>system measurement lists?
Most of this patch series is about policy per namespace. So, basically we propose
one policy per namespace, so each namespace (container) could define what to
measure and appraise. On our design, until a new namespace defines a custom 
policy, it is subject to the system policy. So, we designed that a namespace will 
always follow an IMA policy no matter what and then the current design is 
flexible enough to cover different ways to assure a namespace follows a policy.
The detail about who/where a custom measurement policy is defined, we already 
discussed previously about the possible options (securityfs symlink, bind mount, 
etc). Again, this detail doesn't compromise the proposed design. 

>- IMA-appraisal
>
>Assuming the IMA appraisal policy requires file signatures, signatures are 
>verified based on the keys on the IMA keyring.  When discussing namespacing 
>IMA-appraisal, we might want different sets of keys in different namespaces. 
>This requires separate keyrings for each namespace.  In some use cases, we 
>might want to include the keys on the system IMA keyring, while in other use 
>cases we might not.
Good point. This still is a future work item we could address in a later patch. 
Additionally, each namespace may require a different measurement template,
and template per namespace is not yet supported on this patch set, but already
in plan.

>Even if real root initially installs the files with their file signatures, stored as 
>extended attributes, how will software be updated, as writing file signatures
>requires root privilege?Capabilities has recently added support to permit root 
>in the namespace to write security.capability.  Similarly when namespacing 
>IMA root in the namespace needs the ability to write security.ima.
If I understood the problem correctly, we just need to replace, in the IMA 
hooks, the capable() calls with ns_capable(). This will make sure the capability
checks will consider the correct namespace setting for the current user 
namespace. For instance, a CAP_SYS_ADMIN could be enabled for a fake 'root' 
user inside a given namespace (container), and that is enough for this fake root 
to set security.ima (through evmctl possibly).

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


>As both Apparmor and IMA use securityfs for policy, it would be nice if their
> method for loading namespace policies would be similar too.
Ok, we need to take a look then.

--
Guilherme