[apparmor] AppArmor profile name and hard link question

[John Johansen]

On 09/17/2014 06:30 PM, Li, Li wrote:
> Hello Seth,
> 
> Thanks for the quick response!
> 
> Well, I did a little bit more digging myself and looks like the problem I have may not be hard/symb link issues. It's file system issue.
> 
right

> The system I have use something called overlay-filesystem. https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/Documentation/filesystems/overlayfs.txt?h=overlayfs.current
> 
okay overlayfs does some interesting things

> The link describe what it does. As I previously thought the two objects/files are hardlink, well it actually may not be, it's the "same" file showing up in both lower and upper layer. So essentially you have two mount points to the same object. It also mean the lookup of a requested object can exist in two "directory" if it exists on both upper and lower. I don't know how significant this have on the AppArmor code, from what I look at, it walks through dentry each time a file object is accessed.
> 
yes, it is a stacked virtualfs, where the overlay filesystem presents inodes
& dentries to the the system, and then loops back into the vfs with the
corresponding mnt/dentry/inode of the underlying filesystem.

> For example, by using overlayfs, we have a lower fs mounted on '/rom', and a higher fs mounted on '/', you will find a exe file under both '/rom/bin/exe' and '/bin/exe' exists. And it's not a "hard link".

correct

> For all practical purpose, all the access to the file is using upper fs, so no one will even notice there're two fs.
>  
Not so for apparmor, because of how this is put together in the kernel
accesses to the overlay show up for each layer.

So for your example, the access to /bin/exe will show up as a lookup to
  /bin/exe, followed by a lookup of /rom/bin/exe except with a twist (see below)

> I did a bit debugging on the kernel AppArmor code, it looks like a "path" lookup failed each time a file under '/bin/exe' is accessed. But if I run it using '/rom/bin/exe', the lookup worked. I also looked at apparmor/path.c code:
> 
yes, this is because of how overlayfs setups the lower mnt

> Let's say the path passed in is 'bin/exe', and walk through the code, the function always return error -13, if the path name is the upper fs path. Hope this might help figure out where the problem is.
> 
again the problem is in how overlayfs sets up its overlay.  To avoid having
the submount showup in certain cases the way it does for aufs (another overlay
filesystem) it uses clone_private_mount() which creates a disconnected
private mount point to hide the fact that vfs is doing a loopback into the
lower mount.

The lower mount is disconnected from the namespace and apparmor notices
this when it does its lookup, and since your profiles are not using
the attach_disconnected flag it rejects the access to the lower mount
which gets propogated back up through.

Currently disconnected paths are a problem for apparmor, there is a crude
work around, but the true fix has not landed yet.

You can add the attach_disconnected flag onto the profile eg.
profile /foo flags=(attach_disconnected) {

}

This will result in the disconnect path lookup being connected to the root
so it will likely show up as /rom/bin/exe to apparmor (your regular userspace
applications will still only see the single file /bin/exe).

The other problem you have is that apparmor policy will need rules to
allow access to these files. There is an alias command that can help
with it.

  alias / -> /rom/,

adding automatically will create rule aliases (essentially doubling the
rules like you need).
Eg. for the rule
  /bin/exe  r,

the alias generated would be
  /rom/bin/exe r,


hope this helps
john