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
signature.asc
Description: This is a digitally signed message part
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
