5 ms·
these Hardening variables have been discussed some years back[1]. this will not take off I'm afraid, because locking these unitfiles down is offloaded to the e
by DyslexicAtheist 1y ago
these Hardening variables have been discussed some years back[1].
this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). Maybe they will? But this same approach hasn't worked with apparmor so why should it work with systemd? Who will do the job?
If you consider apparmor maintainers provide skeleton-templates in many cases that will make the parser stop complaining. ("look I have a profile so apparmor shuts up, but don't take too close a look OK")
Then there is firejail, which some argue[2] is snake-oil considering the high level of administrative glue compared to its massive attack-surface (also it's a setuid binary).
I didn't mention SElinux since I don't know a single person who had the joy (or pain depending on perspective) of working with it. But again, seems the expectation to implement security with it is shifted to the user.
[1] https://news.ycombinator.com/item?id=22993304 https://news.ycombinator.com/item?id=22993304
[2] https://github.com/netblue30/firejail/issues/3046 https://github.com/netblue30/firejail/issues/3046
- ptman 1y agoIt would be nice to be possible to do the hardening of services via allowlisting instead. E.g. AllowNothing=true and then start adding what is allowed to make the service function.
- isodude 1y agoI think that pledge[0] offers that functionality [0] https://github.com/jart/pledge https://github.com/jart/pledge
- dralley 1y ago> this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening https://fedoraproject.org/wiki/Changes/SystemdSecurityHarden...
- DyslexicAtheist 1y agothanks for the link, this is great news.
- dfc 1y agoIt says the change was dropped? I guess at least they tried.
- ciupicri 1y ago> Change is dropped because of inactivity. Owner is welcome to resubmit if the work is picked up again.
- Palomides 1y agoimho adding a few lines to the systemd unit file is waaaaaay easier than apparmor and really, these should be written by the developers, not distro maintainers poking around on my Ubuntu machine, a few daemons have some hardening, chronyd looks pretty good
- jcgl 1y ago> this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user Maybe your point is that this isn't done by the vendor in practice. And I'm sure there's room for lots of improvement. However, one of the great things about how systemd units can be provided by the vendor and seamlessly tweaked by the administrator is that the vendor (i.e. packager and/or distro) can set these up easily. There definitely are packages that ship with locked-down files. Tor and powerdns (pdns) are two off the top of my head. → Overall exposure level for pdns.service: 1.9 OK → Overall exposure level for tor.service: 7.1 MEDIUM
- DyslexicAtheist 1y agoI think it should be done by the maintainer of the software not by the distro. My concern is that these features are available since at least 5 years and it has not yet caught on (regardless of what this blog article recommends). It would be great to see it implemented but for now at least on Debian/sid the situation is as follows: UNIT EXPOSURE PREDICATE ModemManager.service 6.3 MEDIUM NetworkManager.service 7.8 EXPOSED alsa-state.service 9.6 UNSAFE anacron.service 9.6 UNSAFE atop.service 9.6 UNSAFE atopacct.service 9.6 UNSAFE avahi-daemon.service 9.6 UNSAFE blueman-mechanism.service 9.6 UNSAFE bluetooth.service 6.0 MEDIUM cron.service 9.6 UNSAFE dbus.service 9.3 UNSAFE dictd.service 9.6 UNSAFE dm-event.service 9.5 UNSAFE dnscrypt-proxy.service 8.1 EXPOSED emergency.service 9.5 UNSAFE exim4.service 6.9 MEDIUM getty@tty1.service 9.6 UNSAFE irqbalance.service 1.2 OK lvm2-lvmpolld.service 9.5 UNSAFE polkit.service 1.2 OK rc-local.service 9.6 UNSAFE rescue.service 9.5 UNSAFE rtkit-daemon.service 7.2 MEDIUM smartmontools.service 9.6 UNSAFE systemd-ask-password-console.service 9.4 UNSAFE systemd-ask-password-wall.service 9.4 UNSAFE systemd-bsod.service 9.5 UNSAFE systemd-hostnamed.service 1.7 OK systemd-journald.service 4.9 OK systemd-logind.service 2.8 OK systemd-networkd.service 2.9 OK systemd-timesyncd.service 2.1 OK systemd-udevd.service 7.1 MEDIUM tor@default.service 6.6 MEDIUM udisks2.service 9.6 UNSAFE upower.service 2.4 OK user@1000.service 9.4 UNSAFE wpa_supplicant.service 9.6 UNSAFE
- krylon 1y agoI vaguely recall looking at the slides from a talk on OpenBSD's approach to this topic, which came down to (paraphrasing from hazy memory) "if it can be disabled, people will disable it; if it needs to be configured, people won't configure it".