Unprivileged user support
kaysond opened this issue · comments
Is your feature request related to a problem? Please describe.
I want to run the container with a non-root user since root is not required for nginx. Running the container with a non-root user as is causes it to fail because the entrypoint can't run sed in /usr/share/nginx/html when the files in there get added as root
Describe the solution you'd like
Should be pretty easy to switch over to the nginx unprivileged container: https://github.com/nginxinc/docker-nginx-unprivileged
The only big change is that it runs on port 8080, since 80 requires privilege
This doesn't actually address the permissions, but you could chmod 666 on everything...
I'm happy to submit a PR for this if you'll take it
Hello and thank you for using my project 😄
What are the security reasons for wanting to run nginx as non-root user for this project? Since the registry UI is containerised without access to the host filesystem... I don't think using unprivileged nginx is necessary and chmod 666 on everything is clearly not a good way to do things 😅.
Since the port will be different, it implies a breaking change and I do not want to force this kind of changes to my users without good reasons.
Thanks for replying!
What are the security reasons for wanting to run nginx as non-root user for this project?
It's a reduction in attack surface. nginx does not need any privileges, so there isn't a reason to run it as root.
Root in a container is root on the host. Yes, the process is isolated through namespacing, but that doesn't mean nginx vulnerabilities and container escape vulnerabilities can't be found, if they don't exist already. There's no reason to take that chance when it's just as easy to run the container as non-root!
I don't think using unprivileged nginx is necessary
Consider this: using privileged nginx also isn't necessary! :)
chmod 666 on everything is clearly not a good way to do things
It wouldn't be any different than the way you have it now: nginx is running as root and already has rw permissions on all the files
Since the port will be different, it implies a breaking change
Fair concern. You can still do aCAP_ADDso that nginx can still bind to port 80 as a non-privileged user.
Alternatively, you may be able to support non-root users without changing the base container, just by modifying your nginx config, Dockerfile, and entrypoint. Docker has the --user flag which changes the runtime user of the container. Right now it fails because of sed not working in the entrypoint, and then it would fail because of the port.
If you fixed the file permissions issue, then you could just make the port customizable via env var (leaving the default at 80 so its a non-breaking change), and I think everything should work.
Principle of least privilege and all that. Most (all?) container escapes have root (or at least CAP_SYS_ADMIN, which is implied by root) as a precondition -- not always a sufficient condition, but generally a necessary one.
Running containers as non-root is a widely followed best practice. (I hasten to add, this doesn't mean containers being launched as root and subsequently dropping root via setuid, but launched directly as non-root where setuid would otherwise fail.)
There are also container orchestration environments that enforce non-root policies. The reason I subscribed to this issue is because I was hosting this project in Kubernetes with a PodSecurityPolicy that prohibited non-root, and I needed to make a special exemption to allow docker-registry-ui to use the privileged PSP. (PSPs are deprecated now but will be replaced by a Pod Security Admission controller where the same approach applies.)
Most projects are following the best practice of not requiring root, so when you encounter one that does, and you're paying attention to the security of your environment, it requires compromising. And when there are no valid technical reasons for the elevated permissions, this comes at the cost of credibility, in my opinion.
I meant to add: if you're concerned about compatibility, it's understandable if the default settings continue to assume root, but at least provide a mechanism to configure things to allow operation without requiring root. You could also consider a separate container image that uses secure configuration out-of-the-box. For example, Gitea has rootless variants of their images.
Hi there, thank you for your messages, you can test the unprivileged user with my PR #234.
With this PR you can run the container as the user nginx which do not have root access.
You can also run the server on a custom port with the environment variable NGINX_LISTEN_PORT. Default values are 80 when the user is root and 8080 otherwise.
Is that OK for you ?