Docker Container runs as root User

AndreK · Jun 13th 2024

Hello everybuddy,

i have installed docker and Compose on my OMV (6.9.16-1) realted to this manual: https://wiki.omv-extras.org/doku.php?id=omv6:docker_in_omv

To run the Containers i have create the user: docker-user with group users

After this i create a Docker File an paste this in:

Code

services:
    minecraft-bedrock-server:
        restart: unless-stopped
        stdin_open: true
        tty: true
        container_name: bedrock-server
        environment:
            - EULA=TRUE
            - SERVER_NAME=Phil
            - MAX_THREADS=2
            - PUID=${PUID}
            - PGID=${PGID}
            - TZ=${TZ}
        ports:
            - 19132:19132/udp
        volumes:
            - CHANGE_TO_COMPOSE_DATA_PATH/bedrock-server-phil:/data
        image: itzg/minecraft-bedrock-server

Display More

In my Global envirment i have this:

The Container came up und runs and i can access the Server. But then i take a look to the Console of OMV i see that the Process belongs to root not to the new User.

Did i make a misstake? Or is this normal?

Kind regards

Andre

chente · Jun 13th 2024

The container must allow the use of a specific PUID and PGID, not all containers allow this. You will need to consult the container creator's documentation.

ryecoaaron · Jun 13th 2024

Quote from AndreK

Did i make a misstake? Or is this normal?

Yes, docker runs containers as root. Running rootless docker is a pain. If you need to run rootless, I would look at podman or k3s/k8s.

AndreK · Jun 13th 2024

Ok i will do a little research.

But isnt it risky to run containers as root?

I see that the process inside the Container acts as root to.

So if anyone "hacks" the process in this Container, he can acts with root rights in my underlaying FIlesystem.

Or did i missunderstood this?

Kind regards

Andre

ryecoaaron · Jun 13th 2024

Quote from AndreK

But isnt it risky to run containers as root?

There are some security vulnerabilities but it generally requires hacking the app running in the container first. Are you running a large production install that is exposed to the internet that many hackers will be interested in? If not, then you don't have many issues. Millions are running docker like this.

Quote from AndreK

I see that the process inside the Container acts as root to.

As designed. What is the problem with this? The point of docker is to have one service running a container. If there is only one service, then it makes little difference what user is running. And since files are not persistent other than volumes, a hack would not survive a container restart.

Quote from AndreK

So if anyone "hacks" the process in this Container, he can acts with root rights in my underlaying FIlesystem.
Or did i missunderstood this?

Potentially.

AndreK · Jun 13th 2024

Quote from ryecoaaron

There are some security vulnerabilities but it generally requires hacking the app running in the container first. Are you running a large production install that is exposed to the internet that many hackers will be interested in? If not, then you don't have many issues. Millions are running docker like this.

One Zero Day Exploid in this popular Image will hit anyone. No Matter if your a Company or a privat person.

And sure this server should be reached from the Internet.

Quote from ryecoaaron

As designed. What is the problem with this? The point of docker is to have one service running a container. If there is only one service, then it makes little difference what user is running. And since files are not persistent other than volumes, a hack would not survive a container restart.

The Data of this Server is persitent. So if the exploid is in the Applikation itsself it would be persitent.

So i will try to get it working without root. For the Image itsself it seems i can set a user for the Server Process.

ryecoaaron · Jun 13th 2024

Quote from AndreK

One Zero Day Exploid in this popular Image will hit anyone. No Matter if your a Company or a privat person.

That just gets the hacker into your container. That doesn't mean they will be able to exploit docker too. Docker would go out of business if it was that easy to exploit docker. The default configuration of docker would be rootless if hacks were that easy. And the chances of a hacker targeting your system is very small. But I already gave you options if you are still worried.

Quote from AndreK

The Data of this Server is persitent. So if the exploid is in the Applikation itsself it would be persitent.

The data is persistent but the OS files and application in the container are not persistent unless they are stored in a volume. That container is designed badly if the application is stored in a persistent volume.

Quote from AndreK

So i will try to get it working without root.

Please don't use the compose plugin then. It will not handle rootless config.

Soma · Jun 13th 2024

Just add the PUID 1004 to the docker group and you will have it's name on the proccess:

Code

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1206676 pi        20   0  265.4g   4.4g 150592 S   0.0  28.6  93:28.50 jellyfin

False sense of safety since the USER being on the docker group has escalated permissions.

But, HEY, it's not root,

AndreK · Jun 13th 2024

Quote from ryecoaaron

That just gets the hacker into your container. That doesn't mean they will be able to exploit docker too. Docker would go out of business if it was that easy to exploit docker. The default configuration of docker would be rootless if hacks were that easy. And the chances of a hacker targeting your system is very small. But I already gave you options if you are still worried.

Correct, but i only talk from the Image itself

I can tell you from personal experience that your Chance to be an Target is very high. We had hosted an application that only has a userbase of around 5k Installations in DACH. And this was the Point were they came in.

Quote from ryecoaaron

The data is persistent but the OS files and application in the container are not persistent unless they are stored in a volume. That container is designed badly if the application is stored in a persistent volume.

The Mincraft Server store all of its data in this data Folder. So if there is a Overflow or someting like this by interpreting Gamefiles it would be persistent until a new Version of the Server is released.

Quote from ryecoaaron

Please don't use the compose plugin then. It will not handle rootless config.

Ok thanks for the Tip

AndreK · Jun 13th 2024

Quote from Soma

False sense of safety since the USER being on the docker group has escalated permissions.

But, HEY, it's not root,

I dont have taken a deep dive yet. Same rights as root?

ryecoaaron · Jun 13th 2024

Quote from AndreK

I can tell you from personal experience that your Chance to be an Target is very high. We had hosted an application that only has a userbase of around 5k Installations in DACH. And this was the Point were they came in.

All I will say is I support internet facing docker containers in a large enterprise company. If you feel better running rootless, go for it. But that doesn't mean you are safe. Hackers can get out of VMs, escalate privileges even when they don't have root, and numerous other things. If you really want to be paranoid, you should run rootless docker/podman in a VM to make it harder to get to the host.

Soma · Jun 13th 2024

Quote from AndreK

Same rights as root?

Code

The Docker daemon runs as root on the host machine, so by default all containers also run as root. The root user inside the container is the same as the root user outside of the container. This isn't a massive issue usually, because it's still isolated from the other containers with all the other namespaces. A process running as root in the container won't be able to access files outside of its jailed directory

Privileged versus Root in Docker: What's the Difference? (howtogeek.com)

So, bottom line is:

Although docker is ran as root, it will be jailed above the docker root folder which by default is /var/lib/docker/container (see it as a chrooted system).

Unless you go passing other volumes binded to the REAL / (root folder) of the OS, it will be very difficult to escalate outside the container.

AndreK · Jun 13th 2024

Ok Thanks for the Infos. I will think about it and how much work I want to do.

chente · Jun 13th 2024

Quote from AndreK

Did i make a misstake? Or is this normal?

The user running the jellyfin container on this system appears as the one running the process, as you can see:

In this case that user is not in the docker group.

Even if docker is run by root, the process should appear with the user configured in the container. If root appears it is because the container is misconfigured or the container does not allow running with a user other than root. As I already said, not all containers allow this.

Quote from Soma

False sense of safety since the USER being on the docker group has escalated permissions.

Including the user running a container in the docker group allows a hacker to escalate to root. Zoki demonstrated this in a thread a couple of years ago, I think it would be a bit difficult to find that thread now, but with patience it would appear. It is not necessary to include the user in this group for everything to work as expected.

AndreK · Jun 13th 2024

Quote from chente

The user running the jellyfin container on this system appears as the one running the process, as you can see:
In this case that user is not in the docker group.
Even if docker is run by root, the process should appear with the user configured in the container. If root appears it is because the container is misconfigured or the container does not allow running with a user other than root. As I already said, not all containers allow this.

I only use this link as an example. I dont use jellyfin image i use the Mincraft image.

And it seems that this Image dont have Support for this.

chente · Jun 13th 2024

Quote from AndreK

I dont use jellyfin image i use the Mincraft image.

I know, I just posted that screenshot so you can see how a container would appear working correctly.

chente · Jun 13th 2024

Quote from chente

Zoki demonstrated this in a thread a couple of years ago, I think it would be a bit difficult to find that thread now, but with patience it would appear

I found it, it's not exactly escalating to root but it's still dangerous.

Post

RE: I have a domain name, do I need to do anything special at setup?

[…]

I do not want to make a long story about it, but ken0201 is effectivly root on the system! Does not matter if he is in the sudo group he can execute any command passwordless.

probably rm -rf /var as user ken0201 would not do any harm but just throws a few permission denied messages.
docker run --rm -v /:/rootfs debian rm -rf /rootfs/var will just wipe the /var directory.

The reason is, that everyone in the group docker is allowed to access the docker socket. docker is running as root, so the…

Zoki

May 13th 2022

Soma · Jun 13th 2024

Quote from chente

I found it, it's not exactly escalating to root but it's still dangerous.

We are talking 2 different things here:

One is by running a container as root with specific volumes binded to it.

The other situation that is talked on that thread, is running docker commands ON THE HOST by a user of the docker group.

And if you look at it, it was binding the / of the OS to the container.

This is something that should never be done on any container (even if with an unpriveledged user)

Even if the command was ran inside the container by bashing to it, the outcome would be the same.

Hence the advise of always have a seperate folder to bind volumes to it.

Whatever happens, it will only affect folders below it.

chente · Jun 13th 2024

Quote from Soma

We are talking 2 different things here:
One is by running a container as root with specific volumes binded to it.

Yes I think you are right. That thread is old and I remembered it differently. In any case, it is not recommended to have one user in the docker group, it is like having two root users. And it's not really necessary for any reason either.

Docker Container runs as root User

chente Jun 13th 2024

AndreK Jun 13th 2024

Participate now!

Similar Threads

portainer container Error binding to 0.0.0.0:3551: bind: address already in use

Procedure to update linuxserver/nextcloud has changed

Docker in LXC with kvm plugin AppArmor issue

Can not reclaim space after deleting files from ext4

General security in an OMV/Portainer installation