The patches are needed to secure lxc. See https://wiki.ubuntu.com/LxcSecurity (a guest can remount the host's devpts. Simply doing 'mount -t devpts devpts /dev/pts' will overlay its private (newinstance) ) Reproducible: Always Steps to Reproduce: 1. emerge hardened-sources, use lxc and apparmor 2. try mounting devpts in container 3. works Actual Results: Mounting devpts in an LCX container succeeds. Expected Results: It should not be possible to mount devpts _IN_ a LXC container! The patches in the upstream apparmor kernel repo used by Ubuntu should be included in hardened-sources.
Which kernel are you using currently?
(In reply to Michael Palimaka (kensington) from comment #1) > Which kernel are you using currently? @kensington: if we need to include patches in the hardened-sources patchset for apparmor, please pass them on to me. But my understanding is that we didn't need any extra patches and that its all upstream.
(In reply to Anthony Basile from comment #2) > But my understanding is that we > didn't need any extra patches and that its all upstream. It is. The patch in $URL appears to add additional features to support mediating of mount operations, and there is an additional patch for network mediation. In the past I avoided trying to have patches included in hardened-sources due to maintenance issues stemming from continual rebasing...but I have no idea if that is still the case.
I am now using a patched hardened 3.12.6 kernel. And it seems to work. The patches are (at least the mount patches) are absolutely needed to create secure LXC containers. Without the patches, everybody can mount the host devpts into the container and access root PTYs in the host, which is obviously a problem. Thats probably why those patches are already included even in ubuntu kernels. The network patches are of course very useful too.
Created attachment 371250 [details, diff] apparmor: mount and network mediation patch for 3.11.7-r1
Created attachment 371252 [details, diff] apparmor: mount and network mediation patch for 3.12.8-r1 and 3.13.2-r1
The both attached patches contain the commits from https://git.kernel.org/cgit/linux/kernel/git/jj/linux-apparmor.git/log/?h=v3.11-aa2.8 and https://git.kernel.org/cgit/linux/kernel/git/jj/linux-apparmor.git/log/?h=v3.12-aa2.8 and implement the mount and network mediation. Here submitted patches contain one change for the lsm.c file comparing to the origin, otherwise they couldn't be applied. I've tested the patches on 3.11.7-r1, 3.12.8-r1 and 3.13.2-r1, I got it applied and the kernel built The network mediation patches solve the issue with apparmor profiles from portage tree (s. example with warnings http://forums.gentoo.org/viewtopic-t-980588-start-0.html) This patches are not taken yet by kernel upstream, but they are implemented within kernels shipped by ubuntu and suse. I suggest to take them to gentoo on the same way till they are merged upstream, apparmor functionality within gentoo is limited without this patches.
@blueness, if you want to include them, I can assist with collecting the latest not-yet-upstreamed apparmor kernel patches. The caveat is I don't actually use them so I can't personally vouch for them, but they seem to be used fine by a number of downstreams.
(In reply to Michael Palimaka (kensington) from comment #8) > @blueness, if you want to include them, I can assist with collecting the > latest not-yet-upstreamed apparmor kernel patches. The caveat is I don't > actually use them so I can't personally vouch for them, but they seem to be > used fine by a number of downstreams. I don't think this is a good idea.
So what gives? As noted by Artem in comment #7, without the patches even the default AppArmor profiles (provided by sec-policy/apparmor-profiles) fail to get enforced due to missing network support. That greatly reduces the usability of AppArmor in general.
@Dainius as I've nothing to add to points, and as I can understand the reasons of Anthony (still if they weren't explained) I maintain this patches by myself in my overlay[1] and try to follow the hardenedsources in portage, so far no problems. [1] https://github.com/artem-sidorenko/portage-2realities
Well, for what it's worth, I applied the patch attached to this bug manually, it did apply correctly, but the kernel wouldn't compile citing that in the aa_umount function "struct path path = { mnt, mnt->mnt_root };" is invalid. Splitting it to have "path.mnt = mnt", "path.dentry = mnt->mnt_root" makes it compile again. In your repository I see the same code, so it might also have the same problem, although I haven't tested it (yet). Thanks for maintaining the patches, though.
(In reply to Dainius Masiliūnas from comment #10) > So what gives? As noted by Artem in comment #7, without the patches even the > default AppArmor profiles (provided by sec-policy/apparmor-profiles) fail to > get enforced due to missing network support. That greatly reduces the > usability of AppArmor in general. AppArmor support in Gentoo is pretty much limited to what upstream provides due to manpower/interest. The hardened team isn't able to take care of yet another MAC and although I'm the primary AppArmor maintainer, my interest is more academic so I can't vouch for and maintain a patch set for hardened-sources.
