dist: harden systemd service unit

[Tachi107]

With this patch the systemd service will now run in a hardened sandbox that limits the kinds of subsystems available to the unit. This improves the overall security of the system, as nextcloud-spreed-signaling becomes almost pointless to exploit.

The most notable changes include:

• The entire fie system is mounted read-only with ProtectSystem=strict
• No binaries are executable, apart from /usr/bin/signaling, with NoExecPaths=/ and ExecPaths=/usr/bin/signaling
• The service cannot see any user on the system apart from the one that is running the process, with PrivateUsers=yes
• Most of the /proc subsystem is inaccessible, and things like system stats may be unavailabe, with ProcSubset=pid
• All home directories are inaccessible, with ProtectHome=yes
• The kinds of permitted system calls are limited, via SystemCallFilter=

I highly recommend you to read the systemd.exec(5) manual page to fully understand what these options do and how they can protect the system.

Unfortunately I haven't been running nextcloud-spreed-signaling in a while, and I can't currently check that these option do not break functionality. I have tested this in a limited environment and it seems that everything still works fine, but it would be better to also check that e.g. the Janus integration is still functional in this hardened sandbox.

[fancycode]

ping @morph027 who provided the initial systemd service

[morph027]

Will add it to my personal instance for testing....thanks for providing and pinging!

[fancycode]

@morph027 did you get a chance to test this?

[morph027]

Ah, thanks for pinging. Works so far. Only thing i noticed is that my systemd might be a bit too old for some features.

systemd[1]: /etc/systemd/system/signaling.service.d/security.conf:7: Unknown key name 'ExecPaths' in section 'Service', ignoring.
systemd[1]: /etc/systemd/system/signaling.service.d/security.conf:10: Unknown key name 'NoExecPaths' in section 'Service', ignoring.
systemd[1]: /etc/systemd/system/signaling.service.d/security.conf:15: Unknown key name 'ProcSubset' in section 'Service', ignoring.
systemd[1]: /etc/systemd/system/signaling.service.d/security.conf:23: Unknown key name 'ProtectProc' in section 'Service', ignoring.

However, it still works.

[fancycode]

Thanks for the feedback.

[Tachi107]

Please note that `ProcSubset` is quite restrictive, and as the systemd.exec(5) manpage says: Note that Linux exposes various kernel APIs via /proc/, which are made unavailable with this setting. Since these APIs are used frequently this option is useful only in a few, specific cases, and is not suitable for most non-trivial programs. In my experience "most non-trivial programs" has not been accurate, and I have used the hardening option on various services without issues, but as Morph hasn't been able to test the option I think it might be appropriate to keep this in mind when dealing with new bug reports. @fancycode, does this project rely on /proc Linux APIs? In any case, thanks for merging :D

…

-- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49