[apparmor] AppArmor profile name and hard link question

[Li, Li]

Hi John,

Thanks for the answer! 

So when AppArmor do a path lookup it only look for the current process's mount? i.e. the upper fs directory tree?

Well, I tried as you suggest to add:
profile /foo flags=(attach_disconnected) {

}

It worked partially for me, because it's a profile flag.  If the process is confined by AA already, i.e in my case if the profile using lower fs path '/rom/bin/process', then all the files accessed by '/rom/bin/process' can be mapped correctly even it's just using upper fs path, like '/lib/aa'.
However, the process cannot be confined if it's running as '/bin/process', even if I had a second profile using name '/bin/process'. Looks like when AA trying to match a profile to the process, there's no where to look for a flag? Or is there a "work around" for set (attach_disconnected) globally?

Anyway, I did a hack temporarily just to verify my theory. Inside path.c:aa_path_name(path, flags, ...) call, I always append 'PATH_CONNECT_PATH' to the flags and it seems to work. I know this is probably not supposed to be the correct way. So please let me know if there's a better and easier way to do that without changing kernel code.

Thanks,

Lee


-----Original Message-----
From: John Johansen [mailto:john.johansen at canonical.com] 
Sent: Thursday, September 18, 2014 12:59 AM
To: Li, Li; Seth Arnold
Cc: apparmor at lists.ubuntu.com
Subject: Re: [apparmor] AppArmor profile name and hard link question

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/Doc
> umentation/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