4 ms·

I use https://static-web-server.net/ https://static-web-server.net/ Cross-platform, written in Rust, straightforward configuration, secure defaults, also has a

by cyrnel 3y ago

I use https://static-web-server.net/ https://static-web-server.net/ Cross-platform, written in Rust, straightforward configuration, secure defaults, also has a hardened container image and a hardened NixOS module. I wouldn't recommend Caddy. Their official docker image runs as root by default [1], and they don't provide a properly sandboxed systemd unit file [2]. [1]: https://github.com/caddyserver/caddy-docker/issues/104 https://github.com/caddyserver/caddy-docker/issues/104 [2]: https://github.com/caddyserver/dist/blob/master/init/caddy.service https://github.com/caddyserver/dist/blob/master/init/caddy.s... EDITED: phrasing

ptx 3y ago
What's wrong with the unit file?
- cyrnel 3y ago
  All linux processes have a default set of permissions that's absurdly large, even when not running as root. Web servers don't need but a fraction of those permissions. This may help: https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd
trillic 3y ago
I use this... [Unit] Description=Caddy webserver Documentation=https://caddyserver.com/docs/ After=network-online.target Wants=network-online.target systemd-networkd-wait-online.service StartLimitIntervalSec=14400 StartLimitBurst=10 [Service] User=caddy Group=caddy # environment: store secrets here such as API tokens EnvironmentFile=-/var/lib/caddy/envfile # data directory: uses $XDG_DATA_HOME/caddy # TLS certificates and other assets are stored here Environment=XDG_DATA_HOME=/var/lib # config directory: uses $XDG_CONFIG_HOME/caddy Environment=XDG_CONFIG_HOME=/etc ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile # Do not allow the process to be restarted in a tight loop. Restart=on-abnormal # Use graceful shutdown with a reasonable timeout KillMode=mixed KillSignal=SIGQUIT TimeoutStopSec=5s # Sufficient resource limits LimitNOFILE=1048576 LimitNPROC=512 # Grants binding to port 443... AmbientCapabilities=CAP_NET_BIND_SERVICE # ...and limits potentially inherited capabilities to this CapabilityBoundingSet=CAP_NET_BIND_SERVICE # Hardening options LockPersonality=true NoNewPrivileges=true PrivateTmp=true PrivateDevices=true ProtectControlGroups=true ProtectHome=true ProtectKernelTunables=true ProtectKernelModules=true ProtectSystem=strict ReadWritePaths=/var/lib/caddy ReadWritePaths=/etc/caddy/autosave.json ReadOnlyPaths=/etc/caddy ReadOnlyPaths=/var/lib/caddy/envfile [Install] WantedBy=multi-user.target
mholt 3y ago
If you want a sandboxed unit file, why not just sandbox it yourself?
- cyrnel 3y ago
  Sandboxing it yourself is fraught because any new feature could cause things like a syscall filter to crash the app. It has to be part of the application build/test/release process to prevent that, like it is in SWS. Besides, we should be creating and using software that is secure by default: https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf https://www.cisa.gov/sites/default/files/2023-06/principles_...
  - mholt 3y ago
    Ah yes, I agree Linux should not let processes have a set of permissions that large by default.

by cyrnel 3y ago

ptx 3y ago

What's wrong with the unit file?

cyrnel 3y ago
All linux processes have a default set of permissions that's absurdly large, even when not running as root. Web servers don't need but a fraction of those permissions. This may help: https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd

trillic 3y ago

I use this... [Unit] Description=Caddy webserver Documentation=https://caddyserver.com/docs/ After=network-online.target Wants=network-online.target systemd-networkd-wait-online.service StartLimitIntervalSec=14400 StartLimitBurst=10 [Service] User=caddy Group=caddy # environment: store secrets here such as API tokens EnvironmentFile=-/var/lib/caddy/envfile # data directory: uses $XDG_DATA_HOME/caddy # TLS certificates and other assets are stored here Environment=XDG_DATA_HOME=/var/lib # config directory: uses $XDG_CONFIG_HOME/caddy Environment=XDG_CONFIG_HOME=/etc ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile # Do not allow the process to be restarted in a tight loop. Restart=on-abnormal # Use graceful shutdown with a reasonable timeout KillMode=mixed KillSignal=SIGQUIT TimeoutStopSec=5s # Sufficient resource limits LimitNOFILE=1048576 LimitNPROC=512 # Grants binding to port 443... AmbientCapabilities=CAP_NET_BIND_SERVICE # ...and limits potentially inherited capabilities to this CapabilityBoundingSet=CAP_NET_BIND_SERVICE # Hardening options LockPersonality=true NoNewPrivileges=true PrivateTmp=true PrivateDevices=true ProtectControlGroups=true ProtectHome=true ProtectKernelTunables=true ProtectKernelModules=true ProtectSystem=strict ReadWritePaths=/var/lib/caddy ReadWritePaths=/etc/caddy/autosave.json ReadOnlyPaths=/etc/caddy ReadOnlyPaths=/var/lib/caddy/envfile [Install] WantedBy=multi-user.target

mholt 3y ago

If you want a sandboxed unit file, why not just sandbox it yourself?

cyrnel 3y ago
Sandboxing it yourself is fraught because any new feature could cause things like a syscall filter to crash the app. It has to be part of the application build/test/release process to prevent that, like it is in SWS. Besides, we should be creating and using software that is secure by default: https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf https://www.cisa.gov/sites/default/files/2023-06/principles_...
- mholt 3y ago
  Ah yes, I agree Linux should not let processes have a set of permissions that large by default.