systemd unit hardening

[SkewedZeppelin]

I've started writing hardened systemd service unit overrides over here:
https://github.com/divestedcg/Brace/tree/master/brace/usr/lib/systemd/system
Thoughts?

[topimiettinen]

Have you used systemd-analyze security? It can be used to analyze individual services for hardening potential and also it gives a short report on system level.

[SkewedZeppelin]

Yes, I've been utilizing that.

[glitsj16]

Nice work! I should revisit my systemd hardening attempts with the help of this collection. FYI, I always liked what @rusty-snake did in fdns.service. A table of systemd option foo translates to firejail option foo would be helpful content for a wiki page (either here or in the firejail repo, or both) IMO.

[SkewedZeppelin]

Lots of goodies there!
A table would be nice to have.

[rusty-snake]

@glitsj16 you wanted you get 😄 https://gist.github.com/rusty-snake/c6d773fc27ddde9071461e0fe4010610

[rusty-snake]

Just found https://wiki.archlinux.org/title/User:NetSysFire/systemd_sandboxing. I really like the Impact-Breakage tables.

cc @NetSysFire

[curiosityseeker]

A nice guide is https://github.com/krathalan/systemd-sandboxing/blob/master/guide.conf

[topimiettinen]

Maybe something to consider: these were not accepted by upstream for example since they may break some configurations, but they certainly work for me:

• Auditd (not OK when random plugins may be used): Harden systemd service linux-audit/audit-userspace#88
• Dbus (not ok when traditional activation is used): https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/106
• Iwd: https://salsa.debian.org/debian/iwd/-/merge_requests/3
• Polkitd (Debian version without mozjs): https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/30
• Smartd (not OK when random plugins may be used): Harden systemd service smartmontools/smartmontools#27
• Udisks (not OK when random plugins may be used): Harden systemd service storaged-project/udisks#647
• Tomoyo-tools: Debian: https://salsa.debian.org/debian/tomoyo-tools/-/merge_requests/1 Upstream: https://osdn.net/projects/tomoyo/lists/archive/users-en/2020-March/000723.html

I also sent a patch to wpa_supplicant list, but the mailing list archives are missing for that time.

[topimiettinen]

I'm using both TOMOYO and SELinux atm. I wanted to use PaX but it wasn't easy on Debian (kernel patch never applied when I tried).

It's possible to lock down user apps as well as system services in TOMOYO. This was actually the reason I switched to TOMOYO from AppArmor, since it couldn't distinguish dbus-daemon running as system service for system bus vs. user started dbus-daemon for session bus. With TOMOYO it's possible since the sequence of execution is different. This is also possible with SELinux (system_u:system_r:system_dbusd_t vs. user_u:user_r:user_dbusd_t).

The tools for TOMOYO aren't great, but I don't think they are that much better with AppArmor. SElinux tools are quite cryptic. For example, I just noticed that actually session dbusd actually runs as user_u:user_r:user_systemd_t and it's not immediately clear to me why it's so and what tools I would use to debug the situation since the logs don't have suspicious AVCs.

Fedora also has a graphical SELinux tool to handle errors but it's not very helpful. The policies by default don't confine user applications at all by default (totally unconfined user unconfined_t vs. unprivileged user user_t). Rules exist for user_t though.

Regarding policies, I think the situation is:

• AppArmor: small number of policies and most for obsolete apps (but it's relatively easy to generate new policies), no total system confinement by default or maybe even possible, confinement starts very late at boot by a system service
• SELinux: lots of policies (also many obsolete), total system confinement is the default except for user apps, starting from executing systemd after initramfs
• TOMOYO: no policies at all so you have to generate your own, total system confinement possible, starting as a first step of initramfs

[curiosityseeker]

@topimiettinen : Very interesting post! I've set up Arch Linux in a VM and can confirm that Tomoyo works with AppArmor (and Firejail, of course). At first, it looks very intruiging that it it is able to confine a complete system with the learning mode. However, I'm having considerable problems to apply it properly:

1. When should I stop learning mode? After a day, a week or a month? And what should I do with all those rules created by it? From AppArmor I know that there are often (mostly) read requests by applications which are definitely not necessary and which I ignore in aa-logprof (or deny in order to make aa-logprof less noisy). But how should I handle those thousands of rules created by the Tomoyo learning mode for the whole system? It's simply impossible to sift through all of them. I guess it makes sense to install Firejail (and AppArmor) beforehand as for all requests blocked by them, the learning mode doesn't have to create own rules, so the total number of rules can be limited to some extent. But there are still too many rules left, and I have no idea what to do with them. But if I don't check them - how can I know if they are possibly too permissive?
2. Another problem is the fact that many processes create (temporary) files with randomized file names. So when switching Tomoyo from learning to enforce mode problems are can be expected. The tool tomoyo-patternize should handle those cases. But if I simply execute it nothing happens, and if I execute tomoyo-patternize /etc/tomoyo/domain_policy.conf I'm getting the error: "Inavlid rule at line 1 in /etc/tomoyo/domain_policy.conf". Line 1 is <kernel> btw. Huh?

What am I missing? Do you have any suggestions how to properly implement Tomoyo?

[topimiettinen]

@curiosityseeker

1. There will be breakage from time to time, for example from library package updates and I don't think there's a good way to avoid that. It can happen with any MAC or even with Firejail with fine grained enough rules. Once there are no errors from learning mode (especially from shutdown of the service), I'll switch to enforcing mode. Then it might break again and needs to be fixed. If you make the rules less precise (for example, exact numbers in library .so.x.y names aren't really interesting), there will be less churn but the rules also become a bit weaker. I also disabled misc::env because it also made rules too fragile.
2. I also didn't like the patternize tool, so I've created the patterns by hand. The error doesn't tell much, but my guess is that use_group line is missing. Even if there are no rules (like file execute /usr/sbin/modprobe), the parser still expect the rules to end with that.

TOMOYO is flexible, so I don't think there's one proper way. Some ideas to consider:

• I haven't bothered creating specific rules for each user app, indeed there would be too many rules. Especially the shell scripts can execute a dozen tools, some of which can be also shell scripts. Instead I have global aggregated rules for all user apps and then specific rules for the few interesting ones, like browsers. This can be done with rules in exception_policy.conf like

keep_domain any from <kernel> /init /usr/bin/run-init /sbin/init /usr/sbin/lightdm
initialize_domain /usr/bin/chromium from any

• Namespaces could be also used, I haven't tried yet.
• Rules which apply to several domains can be shortened with path_group and acl_group features.
• I'm using SELinux which can aggregate several apps under one rule (for example, all games should run with type games_t). I think it has a bit better methods of enforcing apps, except I'm not happy with its network rules, so I made new TOMOYO profiles which only check network access. So in those cases I rely on SELinux for file system rules and TOMOYO for network rules.
• If you want to try confining the system from earliest possible moment in initramfs (which BTW is a great way to learn what happens under the hood in very early boot) here's how it works. Note that this means that all your old rules need changes to handle the init sequence (something like <kernel> /init /usr/bin/run-init /sbin/init instead of <kernel> /sbin/init). I have a hook script for (Debian) initramfs-tools:

#!/bin/sh -e

PREREQS=""

prereqs() { echo "$PREREQS"; }

case "$1" in
    prereqs)
    prereqs
    exit 0
    ;;
esac

. /usr/share/initramfs-tools/hook-functions

mkdir -p $DESTDIR/etc/tomoyo

files="domain_policy.conf exception_policy.conf manager.conf profile.conf stat.conf"
for f in $files; do
        cp -aL /etc/tomoyo/$f $DESTDIR/etc/tomoyo/
done

copy_exec /sbin/tomoyo-init

cat > $DESTDIR/init.tomoyo <<EOF
#!/bin/sh
if [ ! -e /sys ]; then
        mkdir /sys
fi
mount -t sysfs -o nodev,noexec,nosuid sysfs /sys
/sbin/tomoyo-init
umount /sys
exec /init
EOF

chmod +x $DESTDIR/init.tomoyo

This is needed so that /sbin/tomoyo-init can copy the rules to /sys as the first step of the boot. Kernel command line needs to be appended with rdinit=/init.tomoyo TOMOYO_trigger=/init. If something breaks, it's easy to edit the command line and remove these to boot with /init (but then the rules may not match anymore). When you change the rules, initramfs must be also updated since they have a copy.

[curiosityseeker]

@topimiettinen : Wow - thanks a lot for this comprehensive reply! A lot of food for thought! It confirms that this statement :

Any experienced Linux administrator should be able to set up and use TOMOYO Linux within a day!

is rather euphemistic to say the least ;-)

I will certainly look into exception_policy.conf to see if it can make things a bit easier. I'm not sure, though, if I can get along with Tomoyo ...

Thanks again! Much appreciated!

[topimiettinen]

😃 I suppose it depends on "set up and use", surely not full system containment starting from initrd...

Maybe a good start would be to focus on containing one domain (for one service) at a time, preferably something which doesn't ever launch other programs like NTP client or DNS resolver, and also it can be restarted without problem. Also systemd (PID 1) is not a great first choice (although maybe logical) since it does so many things, like mounting, creating files, launching services etc.

[SkewedZeppelin]

It seems you can't respond to a specific discussion thread from email.