[apparmor] How extensively does AppArmor lock down Docker containers?
Jamie Strandboge
jamie at canonical.com
Tue Oct 25 18:08:20 UTC 2016
On Tue, 2016-10-25 at 10:47 -0700, Jessica Frazelle wrote:
> 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.
>
Well, the policy needs to be designed for this isolation. Eg, docker knows where
the container's files are stored, so it would have file rules to allow access to
those files but not the other container's files. You'd also rather than using
bare rules like this:
signal,
dbus,
ptrace,
unix,
would instead have (where '<container name>' is the security lable/profile name
for the container):
signal peer=<container name>,
dbus peer=(label=<container name>),
ptrace peer=<container name>,
unix peer=(label=<container name>,
In this manner, each container can only access its own files and do IPC with
itself.
> 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.d
> > > > > > ocke
> > > > > > 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/list
> > > > info
> > > > /apparmor
> > > >
> > >
> > > --
> > >
> > >
> > > Jessie Frazelle
> > > 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
> > > pgp.mit.edu
> > >
> > --
> > Jamie Strandboge | http://www.canonical.com
> >
>
>
--
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/997aa0ed/attachment-0001.pgp>
More information about the AppArmor
mailing list