They do! For a long time now, since I believe 1.2 (for reference they are now on 1.12)
On Tue, Oct 25, 2016 at 10:17 AM, Jamie Strandboge <[email protected]> wrote: > On Mon, 2016-10-24 at 11:43 -0700, John Johansen wrote: >> On 10/23/2016 04:26 PM, Sam Ghods wrote: >> > >> > We are evaluating moving from CentOS/SELinux/Docker to >> > Ubuntu/AppArmor/Docker and had a question regarding AppArmor. >> > >> > Docker's SELinux policy specifically uses Multi Category Security (MCS) to >> > enforce that each individual container on a system can only access the >> > files >> > on the host labeled for that specific container (more details: article >> > <http >> > s://opensource.com/business/14/9/security-for-docker>, presentation >> > <https://www.youtube.com/watch?v=a9lE9Urr6AQ>). That is, if two Docker >> > containers A and B are spun up on a single host, the default SELinux >> > security policy that comes with Docker will actually enforce that in the >> > event of a breakout, the linux process in container A will not be able to >> > access the files belonging to container B. Not only that, but the only way >> > files can be mounted into a container from the host is if the volumes are >> > suffixed with ":Z", thus telling Docker to make sure to add the relevant >> > MCS >> > labels to the files on the host in that path so that the container can >> > access them. >> > >> > On the contrary, I cannot find any references to a similar mechanism in >> > AppArmor. Instead, Docker's default AppArmor profile >> > <https://docs.docker.co >> > m/engine/security/apparmor/> seems to primarily be about denying access to >> > specific filesystem paths and host resources, not about denying access >> > between containers. >> > >> > My question is, if we use Docker's default AppArmor profile, will we get >> > the >> > same effective protection as using SELinux as described above? Will >> > AppArmor >> > block access from one container to another container's files? If yes, how >> > does it accomplish it? >> > >> I am unfamiliar with what Docker is doing with AppArmor so take the following >> with a large grain of salt. >> >> From the default profile and very limited looking I would say no, Docker's >> use >> of apparmor is not protection one container from another. >> >> There are a few ways to achieve this in apparmor, libvirt and lxc use per >> container generated profiles so that paths can be rewritten and each >> container/domain gets its own unique profile. >> >> Another approach that could be used would be policy namespaces and variables >> to provide something more akin (but definitely not MCS) to the MCS that >> selinux is doing. In this approach you have a single base profile and load it >> to a unique policy namespace for each container. The variables need to be set >> to the correct paths on a per container basis. > > To add to this: until Docker supports per-container profiles for AppArmor like > libvirt and lxd do, you can define your own profiles outside of Docker and > then > use --security-opt to specify that the container should be run under that > profile. This has a nice property that you can tailor the profile for the > container, but the downside is you are managing it outside of Docker itself. > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > AppArmor mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/apparmor > -- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
