To nitpick from those replies: ---
> PrivateDevices=yes > sets up a new /dev mount for the executed processes and only adds API pseudo > devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo > TTY subsystem) to it, but no physical devices such as /dev/sda, system memory > /dev/mem, system ports /dev/port and others On my Debian system: $ id nginx uid=112(nginx) gid=121(nginx) groups=121(nginx) $ /bin/ls -la /dev/mem /dev/sda /dev/port crw-r----- 1 root kmem 1, 1 Mar 30 20:26 /dev/mem crw-r----- 1 root kmem 1, 4 Mar 30 20:26 /dev/port brw-rw---- 1 root disk 8, 0 Mar 30 20:26 /dev/sda As nginx workers run as unprivileged user, that hardening is already applied as a part of a standard operating system privilege separation. By default nginx master process indeed starts as a root user, but does not do a lot of things which might have a potential security impact. --- > PrivateTmp=yes > sets up a new file system namespace for the executed processes and mounts > private /tmp and /var/tmp directories inside it that is not shared by > processes outside of the namespace We already had that enabled some time ago, and it caused non-obvious issues with configurations that use /tmp to store temporary files for different reasons. --- > ProtectSystem=full > mounts the /usr and /boot directories read-only for processes invoked by this > unit. If set to "full", the /etc directory is mounted read-only, too It's effectively read-only as nginx worker processes run under non-privileged users even without that systemd flag, same as for PrivateDevices. --- --- Given that there are confirmed protections already in place (the NGINX master process does nothing more than read configuration files and bind to privileged ports, all actual nginx worker processes that handle data run as the `nginx` or `www-data` unprivileged workers), and that changing some of these flags introduce potential major regressions, we probably should Tread Lightly with enabling these. And to really quote the original reply: > All in all, I believe that kind of configuration hardening might make > sense in the specific scenarios, but not something we can enforce on all > our users by default. I get the need for security and sandboxing and stuff can help with that but we have to really let further hardening be handled by the endpoint sysadmins. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2136126 Title: insufficient security settings for nginx systemd services To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/2136126/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
