dbus and rarely used systemd features (like trusting values from BIOS to create files in your fs root) included for vms but left laying around on baremetal builds will be the major attack vectors on linux for years to come.
upvoted as we need as much visibility on all this mess.
It's not just a systemd thing, all the sandboxing/apppification frameworks (flatpak, snap, etc) heavily rely on dbus as their primary way of communicating with the sandboxed apps, and are constantly adding new dbus interfaces. It is the biggest and most obvious attack surface for sandbox escapes, and the more opaque dbus is, the harder it is to assess their risks.
> like trusting values from BIOS to create files in your fs root
if you can't trust your BIOS, how are you going to be able to trust anything else on your system?
It all starts with the BIOS being (password or otherwise) protected to not be modifyable without authentication and then goes into secure booting your signed UKI (or whatever other signed way). From there you can have it mount your encrypted drive or load another signed root image.
That is like the minimum needed to be able to trust that what you are running is indeed something you can trust and nothing random has been inserted inbetween.
upvoted as we need as much visibility on all this mess.