Additional hardening for Docker-Compose

[TommyTran732]

Nitter runs as root inside of the container, which is unnecessary, so I just force it to run as 998:998. Ideally, you can make it run as an unprivileged user inside of the Dockerfile itself, but it's still good practice imo to force the container to run as an unprivileged user via docker-compose.

Redis already runs as an unprivileged user (998:1000) inside of the container, but I also force the container to run as said user in the docker-compose.yml file.

read_only: true is set as there is no reason for there to be any write to either of these containers outside of the bind mounted directories.

no-new-privileges:true and cap drop all are set because there is no reason for these containers to use capabilities or elevate privileges.

[mikroskeem]

If user is already set by upstream, it's unnecessary to do it here.

[mikroskeem]

#763 would introduce an unprivileged user into the container and would make this option unnecessary. Perhaps wait for that?

[TommyTran732]

#763 would introduce an unprivileged user into the container and would make this option unnecessary. Perhaps wait for that?

It would still be nice to force a UID/GID in the docker-compose file rather than trusting the container though?

[mikroskeem]

Why?

[TommyTran732]

Because the point is reducing trust in the container?

[mikroskeem]

That's unnecessary when container has user explicitly configured, achieving essentially the same thing without needing to worry about keeping UID & GID in sync. Most of Nitter instance operators should be able to trust Dockerfile and docker-compose.yml files from the same repository at least.

[TommyTran732]

You sure? Because I would be nice to account for the event of the UID/GID inside the container being changed for whatever reason - malicious docker registry, malicious maintainer, etc.

[mikroskeem]

In that case setting user makes even less sense, because if you cannot trust container registry nor maintainer, you'll build the image by yourself - and what you see in Dockerfile is what you get.

[TommyTran732]

I don't see how it makes less sense. This is just generally limiting the container's permissions to protect the host.

This is analogous to me saying "Let's apply sandboxing onto X app" and you are saying "Let's just trust X app to sandbox itself, and if you don't trust it to do so then compile it yourself".

It really doesn't hurt to force the UID/GID via the docker-compose file, so I don't get what the problem is. It can coexist with the user being set inside the container as well.

[ghost]

IMO, this should be merged. I've been running this exact compose writeup and I've had zero issues.

In general, it's good to lock down containers as much as possible. Even if users are building their own containers from the Dockerfile or pulling from the remote registry, it's wise to have these implemented.

It's not only for security reasons but also for general education. Docker Compose is a very complex write-up and even I didn't realize you could set a container to read_only.

Lack of trust is also important. Yes, I agree that people pulling from the remote registry or building via Dockerfile should be able to trust the file. However, this doesn't eliminate the possibility of a potential bug turning up where a user can access a Docker container from a vulnerability from the site (even if that's not possible or highly improbable).