On Tue, 2016-10-25 at 10:23 -0700, Jessica Frazelle wrote: > They do! For a long time now, since I believe 1.2 (for reference they > are now on 1.12) >
My understanding was that docker creates a 'docker-default' AppArmor profile which it launches every container under. This is great for host protection, but it means that all containers have the same security label (ie, 'docker-default') and therefore there is no MAC-enforced isolation. For AppArmor on docker to have container isolation like SELinux with docker, or AppArmor with libvirt and lxd, then docker would need to create/load container-specific policies (that could be based on the docker-default template of course, just loaded into the kernel under a different name (which translates to security label) with docker run specifying this different name for the security label (instead of docker- default)). Please correct me if docker has added this feature and I've missed it-- it would indeed be a nice feature for docker to have. > 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.docke > > > > r.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 > -- 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
