Re: systemd-analyze security as a release goal
RL <richard.lewis.debian@googlemail.com> writes:
> Russell Coker <russell@coker.com.au> writes:
>
>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
>>
>> I think we should make it a release goal to have as many daemons as
>> possible running with systemd security features to aim for a low score
>> from "systmd-analyze security".
>
>
> This repos from Trent Buck has a lot of research -
> https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES
>
> (One of the issues for services that send email is that it is very
> easy to break exim)
Hello, I am a nosy person!
I am pleased to see everyone I have pestered about systemd hardening
since 2018 has already commented on this thread :-)
The git repo mentioned above is mostly for Debian 9.
I have later work against Debian 11, but
it's mostly part of a private ansible repo.
I have pushed some into debbugs already.
(SOMEWHERE in "bts show from:trentbuck archive=both"...)
Below is a brain-dump of some new notes I wrote today.
I broadly agree with Marco and Simon sentiments.
Hardening any daemon that can run arbitary hook scripts (e.g. smartd) is going to inconvenience at least 1 person.
I think there's room for improvement, though.
I think at least some units can be hardened by packagers in a way that 99% of users don't notice, and
debian/NEWS can warn users "if you're an edge case, do X to undo this change".
We've had similar cases where e.g. sshd dropped sha1, or
where X.service gradually dropped backcompat with /etc/default/X, or
where msmtp had apparmor hardening on by default, then downgraded it to an opt-in debconf question.
We can also add wiki / hardening-howto documentation to help admins/users opt in to hardening (a la aa-genprof), but
based on my experience with aa and selinux, I don't think that will give good bang-for-buck.
Since systemd units support dropins, we could also provide a single
"harden-all-the-things" package that simply provides a lot of
/lib/systemd/system/X.service.d/harden-all-the-things.conf
errata. This would work similar to how apparmor-profiles-extras works currently --
if you don't care about security, you just don't install that package at all.
I suspect that will also stagnate, though, so it's better to do hardening in each package where possible.
My rules of thumb so far are:
* Start with the most popular units, i.e. sort by popcon.
* Start with units with a clear "do one thing, well" mission,
e.g. e2scrub@, ntpsec-rotate-stats
* If it runs its own process manager (e.g. postfix's "master"),
don't bother trying to harden it.
Start talking to upstream about whether this could be a generator creating native socket-activated systemd units?
If systemd is missing necessary capabilities (e.g. sshd's MaxStartups=), talk to systemd about how to add these?
* If it sends mail via /usr/sbin/sendmail,
don't bother trying to harden it.
If it sends mail via smtp://localhost, that's MUCH easier.
Start encouraging upstreams to do that instead?
(Sysadmins can bind-mount /usr/sbin/msmtp to /usr/sbin/sendmail within the service,
so that a daemon calling /usr/sbin/sendmail will end up talking to exim/postfix/msmtpd on [::1]:25.
Packagers probably can't get away with that.)
* If it can run arbitrary admin-configurable hooks,
don't bother trying to harden it.
For example, smartd and zfs-zed both *by default* only send email, but
in theory you can make them flash LEDs on the front panel by running /opt/broadcom/LSIctl.
Or make demons fly out of your nose.
* If it's sshd or equivalent (used interactively by admin, forks "sudo" &c),
don't bother trying to harden it.
* You don't have to get the score down to 2.
Even getting most scores down from ~9 to ~6 is worthwhile.
Moving pidfiles from /run/%p.pid to /run/%p/%p.pid and
letting systemd do the User=%p can help quite a bit.
Often upstream code needs some minor massaging to make that work cleanly.
Socket activating can help, e.g. prayer (webmail) had undocumented ability to use socket activation,
which meant you could harden its ability to bind to low ports.
* MariaDB upstream is a good example of a reasonableperson-test "middle ground" level of default hardening.
https://mariadb.com/kb/en/systemd/#useful-systemd-options
* If you have to support both Debian N and Debian Nbpo,
with the same config file,
some hardening features in bpo are problematic and not worth your time.
(For example, SystemCallFilter= landed before SystemCallFilter=@foo.
If you tried to use SystemCallFilter=@foo on the older system,
it'd get confused and block ALL syscalls.)
Here's my most recent notes (from June 2023) about then-Debian 11 servers at work.
They're in production and working OK.
HOWEVER, they include quite a bit of "I know *I* don't need X, therefore I am OK with hardening X away."
For example, I know PHP and MariaDB run on the same host, so I can disable AF_INET entirely and use AF_UNIX.
bash5$ for i in light heavy obese delta; do ssh $i systemd-analyze security |
sed s/^/$i\\t/; done | sort -k3,3nr -k2,2 | column -t
HOST UNIT EXPOSURE PREDICATE HAPPY NOTES
delta collectd.service 9.6 UNSAFE 😨 TODO
heavy collectd.service 9.6 UNSAFE 😨 TODO
light collectd.service 9.6 UNSAFE 😨 TODO
obese collectd.service 9.6 UNSAFE 😨 TODO
delta dbus.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy dbus.service 9.6 UNSAFE 😨 IMPOSSIBLE
light dbus.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese dbus.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy dkimpy-milter.service 9.6 UNSAFE 😨 TODO!
delta getty@tty1.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy getty@tty1.service 9.6 UNSAFE 😨 IMPOSSIBLE
light getty@tty1.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese getty@tty1.service 9.6 UNSAFE 😨 IMPOSSIBLE
delta libvirtd.service 9.6 UNSAFE 😨 TODO
heavy libvirtd.service 9.6 UNSAFE 😨 TODO -- REMOVE THIS? Alloc never ended up using this.
light nut-driver.service 9.6 UNSAFE 😨 TODO
delta nut-monitor.service 9.6 UNSAFE 😨 TODO
heavy nut-monitor.service 9.6 UNSAFE 😨 TODO
light nut-monitor.service 9.6 UNSAFE 😨 TODO
light nut-server.service 9.6 UNSAFE 😨 TODO
delta polkit.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy polkit.service 9.6 UNSAFE 😨 IMPOSSIBLE
light polkit.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese polkit.service 9.6 UNSAFE 😨 IMPOSSIBLE
delta rc-local.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy rc-local.service 9.6 UNSAFE 😨 IMPOSSIBLE
light rc-local.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese rc-local.service 9.6 UNSAFE 😨 IMPOSSIBLE
delta rsyslog.service 9.6 UNSAFE 😨 TODO
heavy rsyslog.service 9.6 UNSAFE 😨 TODO
light rsyslog.service 9.6 UNSAFE 😨 TODO
obese rsyslog.service 9.6 UNSAFE 😨 TODO
delta smartmontools.service 9.6 UNSAFE 😨 IMPOSSIBLE? (on-error hook could be arbitrary, but MOSTLY just emails)
heavy smartmontools.service 9.6 UNSAFE 😨 IMPOSSIBLE? (on-error hook could be arbitrary, but MOSTLY just emails)
light smartmontools.service 9.6 UNSAFE 😨 IMPOSSIBLE? (on-error hook could be arbitrary, but MOSTLY just emails)
obese smartmontools.service 9.6 UNSAFE 😨 IMPOSSIBLE? (on-error hook could be arbitrary, but MOSTLY just emails)
delta ssh.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy ssh.service 9.6 UNSAFE 😨 IMPOSSIBLE
light ssh.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese ssh.service 9.6 UNSAFE 😨 IMPOSSIBLE
delta sshguard.service 9.6 UNSAFE 😨 TODO
heavy sshguard.service 9.6 UNSAFE 😨 TODO
light sshguard.service 9.6 UNSAFE 😨 TODO
obese sshguard.service 9.6 UNSAFE 😨 TODO
delta udisks2.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy udisks2.service 9.6 UNSAFE 😨 IMPOSSIBLE
light udisks2.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese udisks2.service 9.6 UNSAFE 😨 IMPOSSIBLE
delta unattended-upgrades.service 9.6 UNSAFE 😨 IMPOSSIBLE
heavy unattended-upgrades.service 9.6 UNSAFE 😨 IMPOSSIBLE
light unattended-upgrades.service 9.6 UNSAFE 😨 IMPOSSIBLE
obese unattended-upgrades.service 9.6 UNSAFE 😨 IMPOSSIBLE
delta virtlockd.service 9.6 UNSAFE 😨 TODO
heavy virtlockd.service 9.6 UNSAFE 😨 TODO -- REMOVE THIS? -- alloc never ended up using this.
delta virtlogd.service 9.6 UNSAFE 😨 TODO
heavy virtlogd.service 9.6 UNSAFE 😨 TODO -- REMOVE THIS? -- alloc never ended up using this.
heavy zfs-zed.service 9.6 UNSAFE 😨 IMPOSSIBLE? (same as smartmontools)
light zfs-zed.service 9.6 UNSAFE 😨 IMPOSSIBLE? (same as smartmontools)
obese zfs-zed.service 9.6 UNSAFE 😨 IMPOSSIBLE? (same as smartmontools)
delta dm-event.service 9.5 UNSAFE 😨 IMPOSSIBLE? (same as smartmontools)
delta emergency.service 9.5 UNSAFE 😨 IMPOSSIBLE
heavy emergency.service 9.5 UNSAFE 😨 IMPOSSIBLE
light emergency.service 9.5 UNSAFE 😨 IMPOSSIBLE
obese emergency.service 9.5 UNSAFE 😨 IMPOSSIBLE
delta lvm2-lvmpolld.service 9.5 UNSAFE 😨 TODO? (will be replaced by ZFS eventually)
delta mdmonitor.service 9.5 UNSAFE 😨 TODO? (will be replaced by ZFS eventually)
delta rescue.service 9.5 UNSAFE 😨 IMPOSSIBLE
heavy rescue.service 9.5 UNSAFE 😨 IMPOSSIBLE
light rescue.service 9.5 UNSAFE 😨 IMPOSSIBLE
obese rescue.service 9.5 UNSAFE 😨 IMPOSSIBLE
delta systemd-fsckd.service 9.5 UNSAFE 😨 IMPOSSIBLE
heavy systemd-fsckd.service 9.5 UNSAFE 😨 IMPOSSIBLE
light systemd-fsckd.service 9.5 UNSAFE 😨 IMPOSSIBLE
obese systemd-fsckd.service 9.5 UNSAFE 😨 IMPOSSIBLE
delta systemd-ask-password-console.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy systemd-ask-password-console.service 9.4 UNSAFE 😨 IMPOSSIBLE
light systemd-ask-password-console.service 9.4 UNSAFE 😨 IMPOSSIBLE
obese systemd-ask-password-onsole.service 9.4 UNSAFE 😨 IMPOSSIBLE
delta systemd-ask-password-wall.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy systemd-ask-password-wall.service 9.4 UNSAFE 😨 IMPOSSIBLE
light systemd-ask-password-wall.service 9.4 UNSAFE 😨 IMPOSSIBLE
obese systemd-ask-password-wall.service 9.4 UNSAFE 😨 IMPOSSIBLE
delta systemd-initctl.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy systemd-initctl.service 9.4 UNSAFE 😨 IMPOSSIBLE
light systemd-initctl.service 9.4 UNSAFE 😨 IMPOSSIBLE
obese systemd-initctl.service 9.4 UNSAFE 😨 IMPOSSIBLE
delta user@1000.service 9.4 UNSAFE 😨 IMPOSSIBLE
light user@1000.service 9.4 UNSAFE 😨 IMPOSSIBLE
obese user@1000.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1024.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1026.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1029.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1030.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1031.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1035.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1036.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1037.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy user@1042.service 9.4 UNSAFE 😨 IMPOSSIBLE
heavy postfix@-.service 9.2 UNSAFE 😨 TODO (probably hard, but worth it as directly exposed to internet)
delta rsync.service 8.5 EXPOSED 🙁 TODO (not active?)
heavy rsync.service 8.5 EXPOSED 🙁 TODO (not active?)
light rsync.service 8.5 EXPOSED 🙁 TODO (not active?)
obese rsync.service 8.5 EXPOSED 🙁 TODO (not active?)
heavy dovecot.service 8.3 EXPOSED 🙁 TODO (probably hard)
delta systemd-udevd.service 8.0 EXPOSED 🙁 IMPOSSIBLE
heavy systemd-udevd.service 8.0 EXPOSED 🙁 IMPOSSIBLE
light systemd-udevd.service 8.0 EXPOSED 🙁 IMPOSSIBLE
obese systemd-udevd.service 8.0 EXPOSED 🙁 IMPOSSIBLE
light arpwatch@dmz.service 7.5 EXPOSED 🙁 TODO
light arpwatch@lan.service 7.5 EXPOSED 🙁 TODO
heavy mariadb.service 6.5 MEDIUM 😐 TODO? (upstream default is "maybe good enough")
delta systemd-machined.service 6.2 MEDIUM 😐 DONE -- upstream default is good enough.
heavy systemd-machined.service 6.2 MEDIUM 😐 TODO -- REMOVE THIS? -- alloc never ended up using this.
delta msmtpd.service 5.8 MEDIUM 😐 TODO? (upstream default is "maybe good enough")
light nsd.service 4.8 OK 🙂 TODO? (upstream default is "maybe good enough")
delta systemd-journald.service 4.3 OK 🙂
heavy systemd-journald.service 4.3 OK 🙂
light systemd-journald.service 4.3 OK 🙂
obese systemd-journald.service 4.3 OK 🙂
heavy cyber-apt-ftparchive-generate@PrisonPC.service 3.2 OK 🙂 TODO
heavy cyber-apt-ftparchive-generate@cyber.service 3.2 OK 🙂 TODO
heavy nginx.service 3.2 OK 🙂
light nginx.service 3.2 OK 🙂
delta systemd-networkd.service 2.9 OK 🙂
heavy systemd-networkd.service 2.9 OK 🙂
light systemd-networkd.service 2.9 OK 🙂
obese systemd-networkd.service 2.9 OK 🙂
delta systemd-logind.service 2.6 OK 🙂
heavy systemd-logind.service 2.6 OK 🙂
light systemd-logind.service 2.6 OK 🙂
obese systemd-logind.service 2.6 OK 🙂
light dnsmasq.service 2.5 OK 🙂
heavy cyber-zfs-backup.service 2.2 OK 🙂
light cyber-zfs-backup.service 2.2 OK 🙂
obese cyber-zfs-backup.service 2.2 OK 🙂
delta systemd-resolved.service 2.1 OK 🙂
heavy systemd-resolved.service 2.1 OK 🙂
light systemd-resolved.service 2.1 OK 🙂
obese systemd-resolved.service 2.1 OK 🙂
delta systemd-timesyncd.service 2.1 OK 🙂
heavy systemd-timesyncd.service 2.1 OK 🙂
light systemd-timesyncd.service 2.1 OK 🙂
obese systemd-timesyncd.service 2.1 OK 🙂
heavy alloc.service 1.4 OK 🙂 <-- This is a PHP5 web app talking to nginx & mariadb via AF_UNIX
heavy cyber-irc-bot.service 1.4 OK 🙂 <-- This is limnoria (supybot)
heavy cyber-mariadb-zfs-snapshot.service 1.3 OK 🙂
heavy ircd-irc2.service 1.3 OK 🙂
heavy monit.service 1.3 OK 🙂
heavy alloc-imap-biff.service 1.2 OK 🙂
heavy pyspf-milter.service 1.2 OK 🙂
light upslog@upset.service 1.2 OK 🙂
heavy apt-cacher-ng.service 1.1 OK 🙂
heavy motion.service 1.1 OK 🙂
heavy opendkim.service 1.1 OK 🙂 TODO -- REMOVE THIS -- replaced by dkimpy-milter
heavy gitit.service 1.0 OK 🙂
heavy klaus.service 0.4 SAFE 😀
heavy collection4.service 0.2 SAFE 😀 <-- This is a fastCGI web app talking to nginx via AF_UNIX
Looking at the same systems now they're Debian 12, I see that:
* fwupd's Recommends caused modemmanager to be installed, ugh.
* systemd
* logind 2.6 -> 2.8 [WORSE]
* networkd 2.9 -> 2.6
* rfkill added
* udevd 8.0 -> 7.1
* motion 1.1 -> 1.2 [WORSE, but this is with my hardening]
* nothing else changed, e.g. rsync.service has exactly the same score as before.
Reply to: