M
M
MintTea2016-07-09 22:43:47
linux
MintTea, 2016-07-09 22:43:47

Why run services in a container as an unprivileged user?

In addition to various articles, this is also advised in the official documentation :

If a service can run without privileges, use USER to change to a non-root user

But after all, this is not about the host, and the service is already isolated from the surrounding system, why further lower privileges for the user? Let's say an attacker found a way to RCE through a service in a container, what exactly could he do wrong from root that he couldn't if the service was started as advised?
I honestly searched the Internet, but the only at least some specific scenario for operating a root account began with the words "Now we will mount the root partition of the host inside the container", which in itself is a little inadequate.
Unfortunately, I have not yet been able to feel the arguments like "it's safer because it's safer." All I see is an unnecessary complication in the container configuration - among other things, now you still need to remember to create a group \ user and make sure that the service has access to the necessary files \ directories \ ports \ etc.
What is the difference?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
K
Kirill Vasiliev, 2016-07-09
@vasilevkirill

tell you what the root user can do with mysql?
Or can nginx / apache certificates, together with private keys, also be given directly to all users?
I hope, you understood me!

D
Dmitry Vapelnik, 2016-07-12
@dvapelnik

Let's start with the fact that initially it is not advised to run anything as root. if you need to run - use sudo so that everything is logged and controlled. just take it on faith. this postulate has been wept with bloody tears by more than one thousand system administrators
further, for a reason, a user is allocated for each service, who has the right to do only what he needs and no more. if you want your service to be portable from container to container and vice versa, then you need to take care that it feels and behaves in the container in the same way as on any other Linux. the environment for the service should be transparent and easily replaceable. if you want to move this service from the container to the host machine and you didn’t care about its rights inside the container (you started it as root and that’s it), then you may have problems when starting it on the host. Your service can do anything, and you will most likely need to rewrite the service so that it can work as it should outside the container
I'm under the impression that service containerization is your silver bullet of security. for example, there is hosting and there are leaky sites on it that hack almost every day and drain data from other sites through them. open_basedir is not set and everything works under Apache without separation via SuID or without mpm-itk. and here you got acquainted with containerization and now you have launched every site in your personal environment and all the chiki-peaks with security. an example contrived by me and not the fact that it is so with you in reality, but the point is not
needs to be done right. not in the way that is convenient and easier, but simply right. we put the service in a container not only in order to isolate it from everything and everyone, like in a cage, but in order to create an appropriate environment for it with the settings and software of the required version that it needs, so that it can run more one instance of this service if necessary and the configuration allows, in order to monitor the operation of each service separately, and so on
this is what I personally encountered and what simply did not let me live. Let's imagine that you have created a service that additionally generates some files. the files are stored in some folder in `/foo/bar/beez_service`, but you mount another folder on the host machine to this folder. Your service is running as root. Your service writes a log and all these files are generated with root rights and with some chmod, which was specified via umask or something else. usually they don't bother with this and the files have chmod 0664 - it is impossible to delete it by a normal user. this is inconvenient to say the least. I understand, you can answer that it is not always necessary to mount folders, that you can use `sudo` on the host machine, that it is not really necessary to delete files through the host machine, and so on

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question