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

Tue Oct 25 17:47:06 UTC 2016

Oh gotcha I misunderstood the need. We launch all containers with the
docker-default profile. You can override it with your own profile,
like you said but you need to write that yourself and pass it with the
flag like you said.

It actually seems like that would be a super easy fix to just copy the
same profile and rename it per container but still if a process was to
break out of a container you are in the same boat whether the profile
is docker-default or docker-whatever, the privilege escalation would
bypass the LSM as well. So I'm not entirely sure what the gain is
here.

On a different note, we were trying to make profiles more human to
interact with but it was not completed before I left and I doubt
anyone is working on it now. But yes it would be nice to have some
sort of "fork" of the default profile and a kind of turing complete
way to add to it.

If anyone is super interested most of the discussion was here:
https://github.com/docker/docker/issues/17142#issuecomment-148974642

On Tue, Oct 25, 2016 at 10:38 AM, Jamie Strandboge <jamie at canonical.com> wrote:
> 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
>

-- 

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu