logging: lockdown the systemd service configuration

logging: lockdown the systemd service configuration

The 'systemd-analyze security' command looks at the unit file
configuration and reports on any settings which increase the
attack surface for the daemon. Since most systemd units are
fairly minimalist, this is generally informing us about settings
that we never put any thought into using before.

In its current configuration it reports

  # systemd-analyze security virtlogd.service
  ...snip...
  → Overall exposure level for virtlogd.service: 9.6 UNSAFE 😨

which is pretty terrible as a score.

If we apply all of the recommendations that appear possible
without (knowingly) breaking functionality it reports:

  # systemd-analyze security virtlogd.service
  ...snip...
  → Overall exposure level for virtlogd.service: 2.2 OK 🙂

which is a pretty decent improvement.

Some of the settings we would like to enable require a systemd
version that is newer than that available in our oldest distro
target - RHEL-8 at v239.

NB, RestrictSUIDSGID is technically newer than 239, but RHEL-8
backported it, and other distros we target have it by default.

Remaining recommendations are

✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER)

  We block FOWNER/IPC_OWNER, but can't block the two DAC
  capabilities. Historically apps/users might point QEMU
  to log files in $HOME, pre-created with their own user
  ID.

✗ IPAddressDeny=

  Not required since RestrictAddressFamilies blocks IP
  usage. Ignoring this avoids the overhead of creating
  a traffic filter than will never be used.

✗ NoNewPrivileges=

  Highly desirable, but cannot enable it yet, because it
  will block the ability to transition to the virtlogd_t
  SELinux domain during execve. The SELinux policy needs
  fixing to permit this transition under NNP first.

✗ PrivateTmp=

  There is a decent chance people have VMs configured
  with a serial port logfile pointing at /tmp. We would
  cause a regression to use private /tmp for logging

✗ PrivateUsers=

  This would put virtlogd inside a user namespace where
  its root is in fact unprivileged. Same problem as the
  User= setting below

✗ ProcSubset=

  Libraries we link to might read certain non-PID related
  files from /proc

✗ ProtectClock=

  Requires v245

✗ ProtectHome=

  Same problem as PrivateTmp=. There's a decent chance
  that someone has a VM configured to write a logfile
  to /home

✗ ProtectHostname=

  Requires v241

✗ ProtectKernelLogs

  Requires v244

✗ ProtectProc

  Requires v247

✗ ProtectSystem=

  We only set it to 'full', as 'strict' is not viable for
  our required usage

✗ RootDirectory=/RootImage=

  We are not capable of running inside a custom chroot
  given needs to write log files to arbitrary places

✗ RestrictAddressFamilies=~AF_UNIX

  We need AF_UNIX to communicate with other libvirt daemons

✗ SystemCallFilter=~@resources

  We link to libvirt.so which links to libnuma.so which has
  a constructor that calls set_mempolicy. This is highly
  undesirable todo during a constructor.

✗ User=/DynamicUser=

  This is highly desirable, but we currently read/write
  logs as root, and directories we're told to write into
  could be anywhere. So using a non-root user would have
  a major risk of regressions for applications and also
  have upgrade implications

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>