Docker-mailserver: Don't require root to run tests

[martin-schulze-vireso]

Is your feature request related to a problem?

When running the tests locally, they must be started as root, as the volume mappings are written to by a root user from inside the container. This requires all commands from the makefile and tests to be run as root and reduces the security inside the container.

Describe the solution you'd like

The container does not run the processes as a privileged user.

Alternatives you've considered

Don't map the folders but copy them using docker cp. This requires explicit syncing, when some file is changed.

Who will that feature be useful to?

Not running under root should improve the overall security and ease the development of tests. (I often forget to prepend sudo when running them.)

What have you done already?

What are you going to contribute?

[erik-wramner]

I like this, but docker is root-equivalent, so in practice there is no major difference. It would be nice to skip the sudo though!

[aendeavor]

@erik-wramner is correct. But I'm all for this too. How can we go about this?

[martin-schulze-vireso]

but docker is root-equivalent, so in practice there is no major difference

I beg to differ. See for example: https://pythonspeed.com/articles/root-capabilities-docker-security/
I am no security specialist but running as root inside the container increases the probability of breaking out into root on the host.

Anyways, since there are no objections for other reasons, my plan would be as follows:

1. find out which services are running as root inside the container
2. prioritize which are easiest to fix. I assume we need to to a case by case analysis
3. create an issue to track the prioritized fixing process
4. create a migration plan for users that have an existing installation which would trigger access denied on the old, root owned, configuration files

Regarding the initial motivation of getting the test mapping root free: Am I right in the assumption that writing to the config volumes is mostly done by our own configuration scripts? If so, that would be a good place to start as we have the most control over them.

[polarathene]

I beg to differ. See for example: https://pythonspeed.com/articles/root-capabilities-docker-security/

The vulnerability it links to was patched. Running as a non-root user was only one mitigation, it could also be avoided with user namespace remapping (can run as root within the container but is treated as a different UID on the host), among several other options.

More importantly, the only mentioned avenue of attack was the system already deployed a malicious image or a malicious service running as root was being run to carry out the exploit.

Beyond that, an attack would first need to breach access into the container, and that's the more realistic attack vector to consider that this project and the user deploying the image would be more responsible over and able to control (vs upstream images/software being compromised).

---

I am no security specialist but running as root inside the container increases the probability of breaking out into root on the host.

Somewhat, yes. I can better avoid the rare chances of a fatal accident from a car accident or plane crash if I stay indoors. It'd be rather paranoid and inconvenient though wouldn't it?

This describes the minimal benefit from running Postfix daemon as non-root (unrelated to Docker).

Don't get me wrong, I'm all for improving security when it's practical. I'm just concerned about how disruptive of a change that might be for this particular project. It may be well meant, but if it's security for the sake of it and requires technical debt negatively impacting maintenance and support or worse introducing bugs / failures due to assumptions... I'm not in support of that :-1:

For example, let's just consider the ports we use. Won't this change require them to be replaced with ports beyond the 1024 range?

• Updating README and Wiki entries along with an announcement of such for users to update their own configs to remap ports
• We only document ports that are exposed for external use. You'd need to ensure that no other ports are used internally (although running a process as non-root that would listen to other ports should raise an error easily enough, unless they're only binded or a child process spawned under certain configurations or delayed conditions/events).
• Not all ports are referenced as numbers, you may only search the codebase we have on github for known ports. Some of these processes are looking up ports via service names/aliases, such as those listed in /etc/services, were you aware of this? (if not, would you likely have missed it and could it have silently introduced a difficult to track bug, what other unknowns might be involved with a project of this scope?)
• When choosing alternative ports, do keep in mind that many are already designated for other services, if you spin up a web server on any of those ports, Chrome for example will complain about the port range being unsafe, and there's a good reason (even has SMTP service as an example and using the browser to attack it).
• Keep in mind some distros differences, /etc/services contents can vary for example, as can UID/GID mappings (as can the related utilities and file hierarchy IIRC). Alpine is commonly found to trip up users due to it's usage of musl, but the UID/GID differences I've found to vary across OpenSUSE, Debian, Fedora, Ubuntu, which tripped me up years ago with a Docker image targeting specific standard user/groups (they just had different IDs or name variations). This is a minor issue, but the project has changed base image in the past, so any system level changes should be well documented for future maintenance. It's unlikely any potential updates to such files being overwritten/modified by the project will cause problems, but it's a possibility.

---

I assume you'd need to take into consideration user supplied files too:

• Project usually takes a bind or volume mount with ENV var locations, then copies those files to another location internally changing permissions.
• For integration with some reverse proxies or other containers that provision TLS certificates, I think there is a script referenced on the Wiki to copy from external location and update the internal copy for Postfix/Dovecot.
• There's also a user patches shell script, which for existing deployments using them may assume certain permissions/ownership for a variety of files.

---

If the changes to support non-root running processes is not going to be invasive by deviating from upstream and standard ports, great, bring it on :+1:

Otherwise, I would like you to really consider the actual value of what is being proposed. For example chasing scores/grades from testssl.sh or Qualys SSL test reports without understanding when it's overkill often brings notable disadvantages, while a non-perfect rating can be plenty secure, despite certain penalties that a tool may raise but don't actually apply or aren't feasible / practical to carry out on just anyone.

We've had some misinformation cited from contributors in this project in the past to explain why cipher suite capability for some macOS/iOS clients ended up broken (which happened more than once from updates that were only security focused, but not well informed). I have preference towards proper justification for changes where possible, sometimes sources are parroting "better safe than sorry" reasons (not referring to your linked resource, but it's a common sight with some blogs on configuring software without properly understanding it).

I'd expect for some valid examples / frequency of Docker containers being breached to perform such exploits in the first place (in particular, those that would present actual risk to this project). Unless you're being specifically targeted, generally the risk isn't as bad as implied.

• We are using well known, widely deployed and maintained upstream software and take security seriously (as best as can be achieved from community vounteers anyhow). That said if the user deploys without taking security into account on their end, we can't do much about that.
• Any vulnerabilities that would allow compromising those projects and thus breaching the container would be responded to promptly, and are more likely to be exploits from upstream where the best mitigation is staying up to date.
• non-root user processes in a container are not immune to being compromised either (as in they can be exploited to access root on the host as well).
• In regards to escaping from container to host root. What would the situation be like without Docker usually? Docker provides some security benefits, but a core reason is packaging/deployment and that it's contained/isolated. I'd be more concerned about the container being breached regardless of root or non-root user, just as I would feel equally uncomfortable if the host system were compromised regardless of user privileges.

---

A better direction might be splitting services out into separate containers, but I think having it all in one deployable image is what users often choose this project for over alternatives that already take the modular approach.

I think the README/Wiki shows configs to run the project with two capabilities added NET_ADMIN(Fail2Ban) and SYS_PTRACE (Not sure about this one?), but splitting that service out to a separate container would complicate things and many users may update without noticing that it needs to be deployed separately.

Perhaps as the official Docker docs for USER suggest, you can still run things as root and drop privileges with gosu in the entrypoint / startmailserver.sh script?

[aendeavor]

Hmm, I guess what @polarathene describes here makes sense. I haven't read through all the links you mentioned, but the detailed explanation makes everything clear, I guess.

Perhaps as the official Docker docs for USER suggest, you can still run things as root and drop privileges with gosu in the entrypoint / startmailserver.sh script?

This would be worth investigating.

[martin-schulze-vireso]

Thanks for the feedback @polarathene. As I said above

I am no security specialist

May main motivation was stated upfront:

When running the tests locally, they must be started as root, as the volume mappings are written to by a root user from inside the container.

This makes test development painful, as forgetting to run everything in sudo can lead to non obvious errors. I just raised the security issues as an additional potential benefit.

Don't get me wrong, I'm all for improving security when it's practical.

I am with you that the measures should have an appropriate cost/benefit ratio and I already alluded to potential pitfalls with the file access rights.

So in summary I would say: We should find ways to fix the test issues without requiring everything to migrate away from root, because that might be too heavy handed.

[erik-wramner]

I think there are two different things here:

1. Running things as root inside the container
2. Running the build partly as root

My comment was about the second. If your host account can run docker commands, then it is root equivalent. It is still nice to be able to skip the sudo commands, but there is no real security benefit.

As for running the services as non-privileged accounts that would really be a security improvement, but I don't think it is easy.