In a container, sshd should not run as root

[micheelengronne]

Add the option to choose the owner of configurations files and their locations.

[micheelengronne]

I am not sure how to handle the groups though. https://github.com/dev-sec/ssh-baseline/blob/micheelengronne-patch-2/controls/ssh_spec.rb#L37

[micheelengronne]

@artem-sidorenko is it ok for you ? Is there smthg I did wrong ?

[micheelengronne]

@chris-rock is it ok to merge ?

[chris-rock]

I think it is a great addition @micheelengronne Can you elaborate the use case a bit more? I'd like to understand why a different path is required.

[chris-rock]

I think that needs to be ssh_custom_user

[micheelengronne]

I normally fixed that in the last commit.

[micheelengronne]

Yes. In the case of a sshd server in a container, the root user should not be used as a container process should not run as root.

In that case, it is not very good to use a reserved root path like /etc/ssh to store configurations.

There is no clear definition of where a configurations ssh folder should be present when a non root user runs sshd. The sshd command is called with the -f flag in that case.

HOME/.ssh is used for the ssh keys and not the configurations. The 2 should not be mixed as they have a different lifecycle (the ssh keys are alterable during the container life, the configurations not).

As there is no clear definition, I think each user should have the choice.

[chris-rock]

Thank you for the clarification. Great improvement @micheelengronne

[micheelengronne]

Thank you. Can you trigger a release please ?

[lpirl]

Just out of curiosity: does this mean that the container ensures the security of the host here? If yes, wouldn't this miss the point of privilege separation and, well, containment?
In other words: If the container is not secure once a process therein attains root privileges, then the container is just not that secure and should rather be run unprivileged, no?

[micheelengronne]

The problem is that unprivileged in the container world (particularly docker, less for podman) is not so unprivileged.

/etc/passwd is shared with the host as many other system files. So if your process runs as root in container, it can be considered as running as root (with some restrictions but still) in the host. That is a security risk.

[micheelengronne]

It is generally a bad pattern to write a CMD without specifying a USER first.

[lpirl]

Thanks for the explanation.

Sorry in case I am missing obvious things here, as I primarily use LXC/LXD. If the container is within a user namespace (uidmap/gidmap), the container should never be able to run a process with the host's uid 0 (however, a process can be run with the container's uid 0, but that is mapped). This should be independent from what files are shared with the host (except maybe the Docker configuration and its control socket, you get it), as far as I understand.

But we don't need to get too philosophical here. I just wanted, for the record, to raise the concern about the container's containment qualities if a root process therein threatens the host security (as in: running nothing as root inside the container is the wrong thing to fix).

[micheelengronne]

for some references:

• https://neoteric.eu/blog/docker-containers-with-root-privileges/
• https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b

The problem is that the main used container provider is docker and they made some wrong choices for their project.
The docker daemon is generally run as root (and is a daemon). uid are not mapped but shared so uid 0 is really root in the host.

Podman fixed these problems but is not very widely used. It is compatible with docker. I would generally advice to use podman over docker when possible.