Is app user secure enough?

[zonescape]

Usually processes in a container are run under unprivileged user because of security reasons. But app user belongs to the docker group. If we assume that there is a bug in the container isolation that causes the container process to execute in the host context, then the app user will have almost the same privileges as root. So what is the meaning of app user? Why not just use root user?

[umputun]

From what I understand being part of the Docker group inside a container has no special meaning or security implications if the Docker socket (/var/run/docker.sock) is not mounted into the container. So, having app a part of docker group by itself doesn't affect isolation, but allows users to mount host's docker.sock in case of need.

[paskal]

@zonescape, could you please include this information in the Readme? This would help address this question for everyone. Your explanation would likely be more comprehensive than what we could come up with.

[zonescape]

@umputun

being part of the Docker group inside a container has no special meaning or security implications if the Docker socket (/var/run/docker.sock) is not mounted into the container.

The same is valid for the root user. Unless Docker socket is mounted into the container, the root user has no special meaning due to isolation. But it becomes dangerous if there is a bug in the container isolation. In this case I don't see much difference between app and root users. Of course inside a container the root user has more privileges than the app but taking into account that all useful stuff in a container is the application data which must be accessible to whatever user running the container process so there is no much difference between any users. The difference reveal itself when there are bugs in the container isolation.

@paskal I am not a security expert, hence the question. All my colleagues run images as root, almost all Dockerfiles here, on GitHub, supposed to be run as root. Nobody cares. In that respect app user is a hardened steel security measure. But I don't know how good it is in the general case.

[umputun]

I’m not a security expert either, but this is my understanding of why using a non-root user inside the container (even when added to the docker group) is preferred over running as root:

• Privileges Inside the Container: Without any potential escape to the host, the privileges of the app user and the root user inside the container are vastly different. The root user can perform any action (inside the container), while the app user is limited, reducing the risk of accidental or malicious changes within the container.
• Impact of Potential Docker Isolation Vulnerabilities: While it’s challenging to predict unknown vulnerabilities, running as a non-root user adheres to the principle of least privilege. In cases where a vulnerability allows for container escape, a process running as root could have unrestricted access to the host system. In contrast, a non-root app user would have limited permissions on the host, mitigating potential damage.
• Defense in Depth: Using a non-root user adds an extra layer of security. Even if the app user is part of the docker group inside the container, this group doesn’t confer additional host privileges unless the Docker socket is explicitly mounted (which it isn’t by default). This separation helps prevent privilege escalation attacks.
• Compatibility with Host Security Mechanisms (e.g., SELinux, AppArmor): Running processes as a non-root user can better integrate with host security mechanisms like SELinux, AppArmor, and seccomp profiles. These tools enforce security policies that further restrict what non-root users can do, even if they escape the container, providing an extra layer of protection against potential exploits.

That said, I can understand the concern about having the app user as part of the docker group or even having a matching docker group inside the container. Personally, I don’t think this is a real security risk; however, if you want to eliminate it and create another flavor of the base image without this group, please feel free to submit a PR. Please note: we can't change the current image as it will break compatibility; however, nothing is preventing us from making a new one, i.e., baseimage.app-paranoid or something like this.