# If we just use Debian 11 default /etc/cron.d/logcheck, with systemd-cron,
# then after an unattended-upgrade, I regularly see this:
#
#     $ systemctl status
#     ● heavy
#         State: degraded
#          Jobs: 0 queued
#        Failed: 1 units
#
#     $ systemctl –state=failed
#       UNIT                           LOAD      ACTIVE SUB    DESCRIPTION
#     ● cron-logcheck-logcheck-1.timer not-found failed failed cron-logcheck-logcheck-1.timer
#
# This is a minor nuisance.
# If we create a native unit with the same name as the /etc/cron.d job,
# systemd-cron will automatically skip the /etc/cron.d job.
# This will make the annoying state=degraded go away.

[Unit]
Description=logcheck — email sysadmin about anomalous log events
Documentation=https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d

# NOTE: if using systemd-cron, "logcheck.timer exists" will automatically disable /etc/cron.d/logcheck.
#       if using vixie cron, you will need to change /etc/cron.d/logcheck to either
#         1) not exist; or
#         2) have something like like "[ -d /run/systemd ] ||"
#
# FIXME: Can I express this cron job as *ONE* .timer/.service pair?
#        https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d
#        The hard part is to supply -R ("reboot mode") iff the unit was started due to OnBootSec=, and not OnCalendar=.
#        For now, I will just accept that reboot jobs lack a "Reboot:" in the subject line.
#        <damjan> twb: if the command is different, then no. you'll have to write two services and two timers
#        I don't think the -R is very important, so I say: "sorry, you can't have that feature anymore".

# logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
[Unit]
ConditionPathExists=/usr/sbin/logcheck

[Service]
Type=oneshot
ExecStart=logcheck
Nice=10
User=logcheck

# logcheck sends an "on reboot" email.
# That ought to wait until the mail can reach a remote smarthost.
# As we aren't gated by vixie crond anymore,
# copy the "after network is up" from cron.service?
# <twb> TIL cron.service will cheerfully start before the network is up, even though
#       cron mails might just flop around on the floor without a remote smarthost.
# <twb> (Specifically I'm thinking of @reboot jobs and msmtp-mta)
# OK so let's just add a wild-ass sloppy guess.
[Unit]
After=remote-fs.target nss-user-lookup.target network-online.target



# Security hardening.
[Service]
CapabilityBoundingSet=
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
DevicePolicy=closed
IPAddressDeny=any
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=noaccess
ProtectSystem=strict
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RemoveIPC=yes
UMask=0077
ProtectHostname=yes
ProcSubset=pid
# Implicitly grants read-write access to /var/lib/logcheck, needed for the inode+offset stamp files.
StateDirectory=%p
# Use msmtp (not postfix) for sendmail.
# Trick logcheck(8)/mail(1) into using msmtp instead of postfix.
# This is because sendmail(1postfix) requires sgid maildrop.
# This would prevent  NoNewPrivileges=yes, which
# is implied by MANY systemd hardening features.
[Service]
BindReadOnlyPaths=/usr/bin/msmtp:/usr/sbin/sendmail
PrivateNetwork=no
RestrictAddressFamilies=AF_INET AF_INET6
IPAddressAllow=localhost