2022 02Feb 06, ReactorScram
This is the systemd unit file I use to run ptth_server on my origin server.
It is stored in /home/user/.config/systemd/user/ptth-server.service.
[Unit]
Description=PTTH WAN Server
[Service]
CapabilityBoundingSet=
DeviceAllow=
DynamicUser=false
Environment="RUST_LOG=ptth=debug"
ExecStart=/home/user/projects/2020/ptth/target/debug/ptth_multi_call_server ptth_server --file-server-root /home/user/share
KeyringMode=private
IPAddressAllow=159.65.219.235
IPAddressDeny=any
LockPersonality=true
MemoryDenyWriteExecute=true
NoNewPrivileges=true
PrivateDevices=true
PrivateUsers=true
PrivateTmp=true
ProcSubset=pid
ProtectClock=true
ProtectControlGroups=true
ProtectHome=read-only
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProtectSystem=strict
ReadOnlyPaths=/home/user/share
RemoveIPC=true
RestrictAddressFamilies=AF_INET AF_INET6
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
# It needs @ipc and @process for some reason, some transitive dependency?
# systemd gives a stack trace in ld-2.33.so and a function name about cpu_features
SystemCallFilter=~@clock @chown @cpu-emulation @debug @keyring \
@memlock @module @mount @obsolete @privileged @raw-io @reboot @resources \
@setuid @swap @sync @timer
UMask=077
WorkingDirectory=/home/user/projects/2020/ptth
[Install]
WantedBy=default.target
It has a lot of security features enabled. I learned about these features from these Hacker News posts and comments:
In the end, I just followed the advice of systemd-analyze --user security ptth-server.
systemd-analyze is strange, because it seems to assume that the service is running as root. But some of the security features, according to the documentation, can't be enabled because I'm running the service as a normal user.
The official systemd docs explain how all the features work:
p.s.: After I wrote this, it occurs to me that I could just run it in a Docker container. But since the blog has no regular readers, it's convenient to use it for live tests of PTTH. So I don't want to pack it up into a container for every little rebuild. You can see that it's not even the optimized build of PTTH, it's the debug build running live!
The relay on the six-five-six-four.com droplet does use a Docker container, because I have a style of running Nginx and reverse proxies in docker-compose which is easy for me to do, and it feels safe. The Docker containers probably provide a similar level of security as this service file, and since they don't run systemd inside them, I don't think it's possible to nest the two.