2022 02Feb 06
Filed under Technical
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.