Run server using non-root user about seafile-containerized HOT 4 CLOSED

Hello,

A similar question has already been asked #59.

First, there are some important things to understand:

1. The user root inside a container does not equal the user root on the host system.
2. The Docker daemon is executed as root, unless executed in the experimental rootless mode. There are other container runtimes, like CRI-O, which are executed rootless by default. Regardless of the container runtime, the users inside the container generally do not have any kind of root access on the host unless you explicitly configure it, see capabilities.
3. The volume being owned by the root user is always intended for Docker.

Looking at issue linked by you, people there seem to confuse a lot of things.

The easiest way to achieve the migration is to change the ownership of the data directory, like this chown -R root:root /path/to/folder.

from seafile-containerized.

Thank you for your response!

Excuse me for not seeing issue #59 and contributing there.

I am not quite sure your points are correct:

1. This is certainly true if the docker engine is run in rootless mode. However, this is as you already said an experimental mode and can therefore not always be used in production. In my case the migration from "root mode" to rootless mode was not successful in the past which is why this is no option for me (unfortunately...).
   In the case the docker engine is run as root, your point is not correct since the internal root user in the container is mapped to the "real" root user on the host [1].
   Various best practices solve this problem by dictating to use a non-root user in containers, as noted for example in [2].
   In this case the non-root user from the container will be mapped to the same non-root user on the host avoiding possible escalation attacks.
2. See 1.
3. Do you maybe have a reference for that? I am not aware of that.

[1] https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container#Container-Defense-in-Depth, most importantly chapter "Container Defense in Depth"
[2] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html, chapter "Rule 2 Set a user"

from seafile-containerized.

It is indeed true that having a user inside the container with the same UID as a root user on the host opens you up for privilege-escalation attacks. Though there are some very important things to consider:

• None of the known attacks can go beyond the mounted host paths or capabilities of the container. This means you either have to have the Docker socket mounted, weird arbitrary bind paths, like mounting the root path of the host into the container or giving the container capabilities.
• The only actually secure solution is running rootless, which doesn't even allow you to do these things in the first place. It's a trade-off between security and features.
• Changing the user inside the container will still leave you vulnerable to capability exploits.

See this wiki page for an overview of Docker privilege escalation attacks.

I want to go into that Red Hat blog post. In my opinion, the example in the "Container Defense in Depth" section is ridiculous. They run a container with the privileged flag and then show that it has access to the host. That's EXACTLY what this flag is for. It gives the container all capabilities. Further, they just throw in the statement that "running the process in the container as a different non-root user offers yet another layer of defense" without substantiating this at all. It's just wrong. If your container runtime already runs rootless, there simply is no way any user in a container can escape user space. This blog post is more like a "Why Docker is bad" article rather than a guideline. Ever since they started their war against Docker they make it sound so easy and great to run everything with Podman and rootless CRI-O. Yet, you find thousands of "How to install Docker on RHEL" guides on the internet.

In my opinion, these are the two best mitigation options:

• The first and the best one is running Docker rootless or using a container runtime, which is by default rootless. The only downside is that for some deployments it just outright won't work or only with very difficult workarounds, e.g. if you need capabilities. I think everybody who has ever run Podman or K8s with CRI-O can relate to that. If you are concerned about security, run everything you can in rootless. It's the only way to achieve maximum security in container virtualization.
• If you can't run rootless, use the UID/GID remapping feature. Your runtime is still executed as root, meaning for instance that you can still use capabilities, but you make sure that at any time users inside a container are mapped to the host user space. This is the only approach that will always work, for every image or compose file, without changing a single line.

About 3.: It's the default standard. If you do not run rootless mode and do not configure anything regarding users, the files in the volume and the volume itself are owned by the root user.

from seafile-containerized.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from seafile-containerized.