[apparmor] How extensively does AppArmor lock down Docker containers?

Tue Oct 25 17:38:10 UTC 2016

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 <jamie at canonical.com>
> 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
> > AppArmor at lists.ubuntu.com
> > 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161025/6af5453b/attachment.pgp>