4 ms·

> 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 i

by 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 ago
I 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
- jcgl 1y ago
  > I think it should be done by the maintainer of the software not by the distro Why would you say that? I would agree that the developer likely has better insight into what the software needs. But the security boundary exists at the interface of the application and the system, so I think that both application devs and system devs (i.e. distros) have something to contribute here. And because systemd allows for composition of these settings, it doesn't have to be a one-or-the other situation--a distro can do some basic locking down (e.g. limiting SUID, DynamicUser, etc.), and then the application dev can do syscall filtering. In any case, I agree that I'd like to see things get even more locked down. But it's worth remembering that, before systemd, there was basically no easy-to-use least-privilege stuff available beyond Unix users and filesystem permissions. The closest you had (afaik) was apparmor and selinux. In both of those cases, the distro basically had to do all the work to create the security policy. Also, n.b., that pdns.service I noted is provided by PowerDNS themselves.

by jcgl 1y ago

DyslexicAtheist 1y ago

I 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

jcgl 1y ago
> I think it should be done by the maintainer of the software not by the distro Why would you say that? I would agree that the developer likely has better insight into what the software needs. But the security boundary exists at the interface of the application and the system, so I think that both application devs and system devs (i.e. distros) have something to contribute here. And because systemd allows for composition of these settings, it doesn't have to be a one-or-the other situation--a distro can do some basic locking down (e.g. limiting SUID, DynamicUser, etc.), and then the application dev can do syscall filtering. In any case, I agree that I'd like to see things get even more locked down. But it's worth remembering that, before systemd, there was basically no easy-to-use least-privilege stuff available beyond Unix users and filesystem permissions. The closest you had (afaik) was apparmor and selinux. In both of those cases, the distro basically had to do all the work to create the security policy. Also, n.b., that pdns.service I noted is provided by PowerDNS themselves.