speedtest icon indicating copy to clipboard operation
speedtest copied to clipboard

Allow the container to run as non-root, with a readonlyrootFS

Open davralin opened this issue 1 year ago • 5 comments

Description

As mentioned from my comment in #663 , the container runs with very high privileges, which stops it from running in environments where higher levels of security is needed/wanted.

Most of the things can be fixed, with some refactoring of both dockerfiles and the entrypoint, however:

  • It will be a breaking change, as it would have to change the listening port in apache to be something above 1024.
  • That will also break the intended (?) purpose of the container being available on default tcp/80 with network_mode: host (network_mode: host will still work, but the container will listen to (for instance) tcp/8080 instead)
  • Something needs to chown the datadir with the sqlite-database, and it can't be the container, because that operation will require root-privileges

You mention Given this configuration, no further adjustments are needed to meet our security goals. - does this mean you don't want to reconfigure the containers so that they run as non-root, with a readonlyrootFS? I'd hate to work on a PR, just for it to be declined.

Why it should be implemented

People who don't want root-containers, with full read/write-access to it's own container's file system.

davralin avatar Nov 18 '24 18:11 davralin

You can go ahead. I understand your intentions better now. As far as I see it there's no need to run in host mode but maybe that's before my time here in the project. Please try to be clear what your changes are when coding them. I will review and comment if something is unclear.

Thank you very much for the effort and input and time!

sstidl avatar Nov 20 '24 06:11 sstidl

It is a common misconception that running root in the container is the same as running root on the host it isn't whether you run as root in the container or some other GID/UID you have the same host capabilities

the port issue can be fixed with the existing envar IMO

scyto avatar Nov 21 '24 01:11 scyto

Please try to be clear what your changes are when coding them. I will review and comment if something is unclear.

My contributions will most likely only be around the Dockerfile's and the entrypoint, and related documentation for that. I'm no coder :-)

At a high-level, my plan is to remove most of the things from entrypoint, and move it to a multi-part Dockerbuild. I think I'm going to deprecate the webport entirely, port-mappings should be sufficient, so it makes no sense to have to configure something twice, in my opinion. I'm not sure yet, how I can fix all the custom copying in entrypoint.sh in a readonlyrootFS (because that's not possible, after all :-) ) - so that might be something that someone else needs to fix.

davralin avatar Nov 21 '24 06:11 davralin

we need the ability to change the port by envar, some of us want to run these on macvlans, or host where port publishing is not required

Wehn you say multipart docker build i want to make sure you are not talking about building the image at run time - just it is multipart for the dcokerfile to produce a static image for the public registry?

scyto avatar Nov 21 '24 17:11 scyto