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

[John J. <joh...@ca...>]

On 05/29/2017 01:34 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote:
> Hi Mimi,
> Thanks for the feedback.
> 
>> (Wow, you should did Cc a lot of people.)
> Reducing the list for now.
> 

<< snip >>

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

Some context to help you

AppArmor policy namespaces are hierarchical in layout. Where a parent
can create children namespaces, and those children can create grand
children. Within securityfs this hierarchy is visible from

  apparmor/policy/

AppArmor tracks which policy namespace a task is in, and this
determines what policy is available to the task, both for enforcement
and visibility. Generally a task with rights to manage policy can load
policy into its namespace and that namespaces children, but a task in
a child namespace can not load policy into a parent namespace, ideally
it shouldn't even be able to see it.

The goal being to allow tasks within a namespace to manage it/ think
about as though it is the root system namespace. Probably the simplest
example for this is LXD on ubuntu where it creates a child namespace
for its container, and the container OS can load apparmor policy
without worrying about the rest of systems apparmor policy.

To achieve this apparmor had to "virtualize" most of its files so that
they change input/output based on the policy namespace of the task
that opens them. This works well for files but does not work for the
policy directory trees.

To deal with the policy directory tree we create a special apparmorfs
which is not available to mount from userspace and we do a kern mount
on it as part of our setup.
 
  apparmor/policy 

becoming a magic symlink that is dynamically resolved to the correct
subtree in apparmorfs for a given policy namespace.  The links look
like

  apparmor/policy -> apparmorfs:[1234]

This gives us the virtualization without having to mess with the mount
namespace (bind mounts), without requiring changes to userspace around
mounts, or management assumptions (securityfs), and it matches with
what nsfs is doing, so there is precedence for this approach.


I will further add, this is just our solution for dealing with the fs
interface. There are currently insufficient hooks in the LSM for
dealing with interactions between policy namespaces and the rest of
the system namespaces.

Lukasz Pawelczyk posted a set of 3 patches a while ago now, focused
on needs for providing some namespacing smack.
  user_ns: 3 new LSM hooks for user namespace operations

I have messed with these and they are worth looking at. I plan to prose
a new revision of the patch series hopefully soon.