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:[email protected]]
Sent: Thursday, September 18, 2014 12:59 AM
To: Li, Li; Seth Arnold
Cc: [email protected]
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
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
