On Wed 07 Dec 2022 23:46:43 +0000, Richard Lewis wrote:
> I have been studying and experimenting - and learning a lot.
> For exim4, i found ⋯
I slurped your exim notes into my repo.
I probably won't do any actual testing with exim myself :-)
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/commits/main/systemd/system/0-EXAMPLES/30-allow-mail-exim.conf
I was indeed originally plannign to push it into Debian as a kind of "apt
install increased-hardening" package.
But I ran into enough nitpicking and static, my current approach is to instead
try to work on individual packages, and
try to push upstreams to be more hardened by default.
e.g. SyscallFilters=@foo isn't backwards-compatible with old systemd, so
you can't use it if you don't know a minimum systemd version.
e.g. Architecture=native works fine until someone does something like "apt
install curl:armhf".
e.g. the whole "if you call /usr/sbin/sendmail, everything becomes messy"
> - whether the unit is 'oneshot' - if so the unit needs to ensure exim has
> delivered the mail before the script exits - adding a small 'sleep' is
> enough - i think otherwise systemd gets confused about what process to
> monitor if the script causes exim to launch.
That doesn't sound right, but I suppose it's possible.
KillMode=process might trigger that.
> - whether or not the unit runs as root or a different user. With User=root
> you can get away with more hardening directives, but i think better to
> continue running as a non-root user
I think you'll find this is just because User=root implicitly disables a bunch
of the settings.
If you set User=root, then "systemctl daemon-reload" then "systemd-analyze
security foo.service",
you will see a bunch of stuff like:
Service runs as root, option does not matter
Service runs as root, option does not apply
PS: "systemd-analyze syscall-filter" is a good thing to look at when dealing
with chown/seteuid.
