Hi, Thank you for your contribution!
26.03.2020 16:37, Dulmandakh Sukhbaatar wrote: > Hello, > > I would like to propose to harden nginx.service with systems configurations, > and this change uses PrivateDevices=yes, PrivateTmp=yes and > ProtectSystem=full configs. And here are excerpts from man systemd.exec man > page. > > 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. > I believe that these configs will harden nginx.service, thus protect OS from > security bugs in nginx. 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. -- Konstantin Pavlov https://www.nginx.com/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
