11

I am running a (QNAP) NAS with Docker functionality ("containerstation"). I thought it would be a lot safer to install apps via containers instead of apps from the store (or 3rd party stores).

Many packages are outdated in their official store and QNAP runs all programs and apps as root/admin (even the webserver), therefore I thought Docker would be a solution.

Now I have some Docker instances deployed and their processes appear to run also as root/admin.

enter image description here

Which makes me think: Is it a false sense of security I have at this moment? Or is using the docker containers much safer than "regular" root?

h4ckNinja
  • 3,006
  • 15
  • 24
Critical joe
  • 193
  • 1
  • 2
  • 9
  • One thing that's not clear here is if the applications inside the containers are running as root, or the `docker` process is running as root on the host. Could you clarify if you are asking about the host processes or the containers? – h4ckNinja Dec 27 '17 at 19:37
  • 3
    I think given that he says that all of the programs ran on the host run as root, we can assume that he's concerned about the processes running as root within docker, as well as being concerned about docker running as root. – Monica Apologists Get Out Dec 27 '17 at 20:20
  • https://security.stackexchange.com/questions/102323/risks-posed-by-docker-daemon-running-as-root?rq=1 may be relevant, at least to whether or not Docker running as root is a problem by itself. – forest Dec 28 '17 at 06:19
  • Docker is running as root always on host. Even if run as other user with docker permissions is very easy to escalate to root with the "chroot trick". Anyway, having apps containerized is a good option. It depends of your container's configuration to know if it could be a problem. – OscarAkaElvis Dec 28 '17 at 08:28
  • By root , you mean user id 0 , if in the container the user root has some other ID like 1001 , it will be a fake root and will not be a security risk – Ijaz Ahmad Oct 15 '18 at 12:38

1 Answers1

13

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability SYS_ADMIN that is needed for mount. However, avoid root in container whenever possible to minimize risks.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

Another option to improve container security is --security-opt=no-new-privileges.

mviereck
  • 359
  • 2
  • 7