APP_UID default of 0 is dangerous about sickgear.docker HOT 3 CLOSED

You are correct to assume that an application running on anything other than root inside the container is more secure, but there are other reasons why root was chosen as the default user for the container. Let me summarise those here, just for future reference.

Security perspective:

• Docker uses multiple methods of restricting the application inside a container so root is not as powerful inside the container as it is outside.
• Depending on an exploit, the attack could be restricted to being root only. In such case, the attacker needs to elevate to root privileges to perform the attach to escape the root. This isn't always the case, but is still worth mentioning
• Care has been taken on the stable branch image not to install anything on the container that isn't strictly needed for SG operations. That way we limit the footprint of available tools inside the container
• Care has been taken to allow mounting the root image as read-only on the stable branch images. This reduces attack vectors even further.

Application perspective:

• SG is generally run against an external shared storage. While it is possible (and I would even recommend doing so) to run SG with APP_UID != 0, it is difficult to get all the permissions correct.
• SG uses a configuration file, which is read and written with the APP_UID, so storing the configuration outside of the container needs to be changed to the UID. While the container does this internally, it might disrupt backups etc.

And finally, subjective points:

• SG is generally run in personal environments. While not running as root makes the application more secure in terms of attack vectors, the other entry points to the environment overweight the security benefits of running as non-root. This generally comes to things like:
  • Do we have secure passwords
  • Are services exposed to the internet
  • Are connections to the service encrypted etc.

So as you can see. I tried to select the reasonable middle ground for the default setup. The image does allow running as non-root if the user so desires and in such cases most likely knows how to set up all the required permissions and other security features so that the environment is secure.

For those not understanding all the aspects of permissions, ownerships and other security related issues, we offer a reasonably secure image out of the box.

I hope this answers the question and explains the reasoning why APP_UID == 0 was selected to be the default.

from sickgear.docker.

Many thanks for taking the time to open a discussion.

Regarding security point 2, I think you are agreeing with me - you are acknowledging that for an attacker to breakout of a container, they first need (or at least highly benefit from) root within the container. By compromising the one service actually executing in the container (i.e. sickgear) the attacker now potentially has shell execution with the privileges of the UID running sickgear which in this case of course is root (UID = 0).

I feel like the argument that getting permissions correct is valid (application, point 1) but is that a reason to make things default insecure? Shouldn't we be challenging users to learn security out of necessity, when we have the opportunity?

On subjective points - I will always expose sickgear to the internet, or at least a VPN. I want to implement security in depth and running any services as root, especially simple web applications, will always be bad practice in my opinion, and it breaks the law of security in depth. When we have a large and constantly changing project like sickgear, new vulnerabilities can be introduced at any stage. What if the git repo is compromised and shell code inserted surreptitiously? If the UID of the app is by default low privileged, we significantly hinder the impact of such an event in terms of escalation through end user infrastructure.

If you were to humour me, what would you propose for an alternative default UID? A built-in low privileged user as part of the image, perhaps?

from sickgear.docker.

Yes, it is possible for an attacker to break out of the container. But at the same time we need to remember that this does require a vulnerability to begin with. So just having root permissions in a default docker environment doesn't mean that you can break out of the container, but you need a vulnerability to escalate privileges from the container restricted environment to system wide root environment. This is comparable to the privilege escalation attacks on Xen and other virtualization platforms, where it is also possible to break out of the virtual machine if a suitable vulnerability is found.

What I'm trying to say is, just by having root inside a container doesn't mean that you can break out of the container.

The default environment isn't insecure, it's just not hardened to the most strict settings. Generally when it comes to security, we need to find a good balance on security and usability. The most secure computer is a computer which is inside a concrete block with just the power cable connected (and even that could be attacked by using some sort of timing attack on the power levels.. in theory..). The issue with being absolutely secure is that it is never usable.

Same applies here. If we harden the environment by default too much, we will start seeing howtos on disabling the security. This has happened in the past as well. Back when Linux was still young, we saw a boatload of sites instructing users to disable certain security features just to get around the strict default security. The end result was that instead of just disabling the features that were preventing the application or functionality from working, they ended up using some generic script that disabled everything. Usually this script was copy pasted from a forum with no real validation of what the script was actually doing.

So yes, challenging people to learn is good. Forcing them to learn is bad. If you try to force someone, they will fight back and usually opt for the easy way out.

And now i'm rambling..

As for the security of unprivileged userid inside docker. That is pretty subjective as well. We have to consider the fact that root inside a docker container is in no way the same thing as root outside of docker. This is assuming that you don't explicitly give the capabilities to the container.

So if you were to set a default alternative UID, I would pick just any UID.. possibly 999 since it's generally not mapped to any user outside of the container. I would set GID to 100 (which in Debian based systems translates to group users. But considering that there is no hard standard on what the UID or GID values are in each distribution, it would most likely end up being something not so useful. So that being said, the only reasonable default would be UID 65534 and GID 65534. That would render the default setup pretty safely unusable when interacting with outside storage and services and force the user to set the desired values manually.

from sickgear.docker.