There’s a good article in Docker’s documentation about security with Docker: https://docs.docker.com/articles/security/
However, it’s not very clear to me how root-privileged processes in the container actually run in the host system, and how I’m supposed to configure SELinux to handle the risk of process “leaking” outside the container.
For instance, I’m running nginx in a container, and when I do “ps” outside the container, I can see all nginx processes.
root 7281 4078 0 01:36 ? 00:00:00 nginx: master process nginx www-data 7309 7281 0 01:36 ? 00:00:00 nginx: worker process www-data 7310 7281 0 01:36 ? 00:00:00 nginx: worker process www-data 7311 7281 0 01:36 ? 00:00:00 nginx: worker process www-data 7312 7281 0 01:36 ? 00:00:00 nginx: worker process
This is not a surprise, since this is the way Docker works – it’s not virtualization where nothing appears outside a VM. With Docker, a container’s processes run on the host OS within namespaces and limited privileges. They are talking directly to the host kernel.
In this situation, I believe I should configure SELinux to secure nginx process instead of docker’s, just like if it was running without docker. Is that correct?
Also, is there any specific Docker configuration more appropriate to run webservers like nginx ?
Assuming of course that you’re using an SELinux-enabled Docker (RHEL/CentOS 7 and Fedora) then you shouldn’t need to do anything aside from make sure that SELinux is enabled and enforcing on the host machine.
The containers created with Docker or virsh are automatically assigned with an SELinux context specified in the SELinux policy.
You may want to check the security context that your container’s processes run under. To do so, add the
-Z option to
ps. For example:
LABEL PID TTY STAT TIME COMMAND system_u:system_r:virtd_lxc_t:s0:c5,c342 26351 ? Ss 0:00 /sbin/init system_u:system_r:virtd_lxc_t:s0:c5,c342 26458 ? Ss 0:00 /usr/sbin/sshd -D
Note that SELinux itself is not namespaced, so you can’t have separate SELinux policies within containers, as if they were independent OS installations.
This also doesn’t appear to be as well-developed (yet) as SELinux for containers managed by libvirt. But in general it shouldn’t be something you need to worry much about.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.