UPDATE: a debian/logcheck.tmpfiles (/etc/tmpfiles.d/logcheck.conf) is also needed. The security hardening I added prevents logcheck from creating it. See attached.
# Hardened logcheck.service started complaining after a reboot: # # systemd[1]: Starting logcheck — email sysadmin about anomalous log events... # logcheck[807044]: mkdir: cannot create directory ‘/run/lock/logcheck’: Read-only file system # msmtp[808400]: host=localhost tls=off auth=off from=logch...@cyber.com.au recipients=logcheck mailsize=1368 smtpstatus=250 smtpmsg='250 2.0.0 Ok: queued as CB96A283D8' exitcode=EX_OK # systemd[1]: logcheck.service: Succeeded. # # It didn't complain BEFORE the reboot, presumably because that dir already existed. # https://salsa.debian.org/debian/logcheck/-/blob/debian/1.3.24/src/logcheck#L653-657 # # Move that "make sure the dir exists" into the separate systemd daemon whose entire job is to do that. # # <twb> I have an existing batch job that I don't want to patch. # It is doing # LOCKDIR=/run/lock/logcheck # if [ ! -d "$LOCKDIR" ]; then mkdir -m 0755 "$LOCKDIR" fi # This fails when the .service is hardened. # Is there a way to make systemd manage that dir? # I initially thought RuntimeDirectory=%p, but that's /run/logcheck not /run/lock/logcheck. # I don't see anything relevant in "git grep -Fw lock -- man". # I guess I can write a tmpfiles.d, and then ReadWritePaths=/run/lock/logcheck... # Oh the latter is probably implicitly there already. d /run/lock/logcheck 0755 logcheck logcheck - -
# 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
[Unit] Description=logcheck — email sysadmin about anomalous log events Documentation=https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d [Install] WantedBy=timers.target [Timer] # /etc/cron.d/logcheck said: "@reboot" # https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d # Round this up to "a little bit after boot". OnStartupSec=2m # /etc/cron.d/logcheck said: "2 * * * *" # https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d # Hourly, two minutes past the hour. # Is there any reason to not just do OnCalendar=hourly? # I guess the concern is overlapping with other @hourly jobs. # Since this is the Debian default, keep it for now. OnCalendar=*-*-* *:02:00
