Hardening nginx.service with systemd

[Konstantin Pavlov]

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/