On Wed, 9 Nov 2022, 08:37 Trent W. Buck, <trentb...@gmail.com> wrote:
> My old (Debian 9) notes about different techniques are here: > > https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES > > This is an amazing resource! (did you consider trying to introduce it into a debian package somehow?) I have been studying and experimenting - and learning a lot. For exim4, i found that it depends on - 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. - 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 This all makes me want to abandon exim for postfix.... but exim is still debian's default. I think this is consistent with what you found for other mtas, but for future reference and to help people searching for how to use exim in a systemd unit, ive been using the following with exim: ------------------------------------------------ ExecStart=/usr/sbin/logcheck ExecStart=sleep 0.1s User=logcheck UMask=0066 ProtectSystem=strict ReadWritePaths=/var/lib/logcheck # for exim - probably debian should allow all of /var/spool and /var/log here ReadWritePaths=-/var/spool/exim4 -/var/mail -/var/log/exim4 # ProtectHome=true is possible, but the message will be # frozen as exim wants to cd to $HOME (for .forward) ProtectHome=read-only PrivateTmp=true PrivateMounts=true DevicePolicy=strict # *cannot set: PrivateDevices=true DeviceAllow=/dev/stdout w DeviceAllow=/dev/stdin r DeviceAllow=/dev/stderr w DeviceAllow=/dev/null rw ProtectProc=invisible ProcSubset=pid RemoveIPC=true ProtectControlGroups=true AmbientCapabilities= # exim needs to change ownership of mail - both when it # receives the mail and when it delivers it to the local user # see capabilities(7) CapabilityBoundingSet=CAP_SETGID CapabilityBoundingSet=CAP_SETUID CapabilityBoundingSet=CAP_FSETID CapabilityBoundingSet=CAP_CHOWN CapabilityBoundingSet=CAP_DAC_OVERRIDE CapabilityBoundingSet=CAP_FOWNER # Anything that implies NoNewPrivileges cannot be set # cannot set: NoNewPrivileges=yes # cannot set: DynamicUser=yes # cannot set: PrivateUsers=true # *cannot set: RestrictNamespaces=true # *cannot set: LockPersonality=true # *cannot set: ProtectKernelModules=true # *cannot set: ProtectKernelLogs=true # *cannot set: ProtectHostname=true # *cannot set: ProtectClock=true # *cannot set: RestrictRealtime=true # *cannot set: MemoryDenyWriteExecute=true # *cannot set - and would break remote delivery: RestrictAddressFamilies=AF_INET AF_INET6 # *cannot set: RestrictSUIDSGID=true # *cannot set: SystemCallArchitectures=native # *cannot set: SystemCallFilter=@system-service # cannot set (due to chown): SystemCallFilter=~@privileged # directives with a * can be set if we use User=root instead of User=logcheck ------------------------------------------------------------- This still needs the tmpfiles.d dropin from your earlier email. However, i wonder if it is better to make logcheck use a single dir for both the lockfile (currently /run/lock/logcheck) and the scratch dir ( currently created in /tmp each time) and then we could use a single RuntimeDirectory=logcheck with RuntimeDirectoryPreserve=yes (to ensure it is not deleted and no clashes if logcheck dies it would retain the current code in logcheck to use a random subdir and delete it on success)
