I have a Docker container (LXC) which runs MySQL. Since the idea behind Docker is generally "one running process per container," if I define AppArmor profiles targeting the MySQL binary, will they be enforced? Is there a way for me to test for this?
First, cgroups are not used to isolate an application from others on a system. They are used to manage resource usage and device access. It's the various namespaces (PID, UTS, mount, user...) that provide some (limited) isolation.
Moreover, a process launched inside a Docker container will probably not be able to manage the AppArmor profile it is running under. The approach currently taken is to setup a specific AppArmor profile before launching the container.
It looks like the libcontainer execution driver in Docker supports setting AppArmor profiles for containers, but I can't find any example or reference in the doc.
Apparently AppArmor is also supported with LXC in Ubuntu.
You should write an AppArmor profile for your application and make sure LXC/libcontainer/Docker/... loads it before starting the processes inside the container.
Profiles used this way should be enforced, and to test it you should try an illegal access and make sure it fails.
There is no link between the binary and the actually enforced profile in this case. You have to explicitly tell Docker/LXC to use this profile for your container. Writing a profile for the MySQL binary will only enforce it on the host, not in the container.
The answer is very likely: no.
The Ubuntu Server guide topic LXC discusses pretty much your exact question and makes the following statement:
Programs in a container cannot be further confined - for instance, MySQL runs under the container profile (protecting the host) but will not be able to enter the MySQL profile (to protect the container).
A better option to avoid exploits having unwanted effects is to confine the user running the container and use userspace LXC containers that leverage the userns feature of the kernel. However,
docker currently - to my knowledge - does not support
In such a case MySQL would - from the hosts perspective - run as unprivileged user, while inside the container it could be run as
root. You can then use
iptables to bind the MySQL to an external port of the host, if needed.