 7️⃣ Here's the 7th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd. In systemd we put a lot of focus on operating with disk images, specifically file system images that carry an expressive GPT partition table – something that we call DDIs ("Discoverable Disk Images"). 7 comments
Many of systemd's tools have a --image= switch that tells them to operate on a DDI rather than directly on the file system. In my personal view, I am pretty sure an OS (specifically: all the code and immutable vendor shipped resources) should be composed entirely from DDIs, because they bring a very high security level (i.e. every single read is validated when it is made), but are nicely composable, … … so that you can have the basic OS image, layers of extensions on top, and finally app images as payload – all shipped as DDIs with strongest cryptographic guarantees. So, while systemd has been strong on DDIs already, there's one thing we did *not* provide until v256: the ability to work with DDIs from unprivileged code. Mounting file systems is after all a privileged operation on its lowest level and (with some exceptions) not accessible to unprivileged users. And that for a reason: kernel file system developers mostly do not consider attacks on the kernel through rogue file system images a security vulnerability. File systems are very complex data structures after all, and guaranteeing that a rogue fs image can't exploit the kernel (or just guarantee algorithmic boundedness) is very very hard. Moreover, file systems can carry dangerous things, such as SUID and SGID binaries, or executables with file system capabilities set. Allowing unprivileged users to just arbitrarily mount file systems is hence a security issue on many levels. With v256 we are opening this up nonetheless – within limits. Specifically, there's now a small IPC interface where clients can pass an fd to a disk image file to, and get back a mount fd they can attach to a location in the file system. To lock this down securely, a couple of requirements are enforced however. Primarily this means: the DDI *must* come with valid dm-verity data and a signature recognized by the system's keyring (well, if this is missing a polkit authorization is attempted – the user might possibly allow this anyway, if polkit is letting them). And the client must also pass in a user namespace fd (which cannot be the system's main one) to which the mount is restricted. Various tools (including: systemd-nspawn, systemd-dissect, RootImage= in service files) have been updated to make use of this new IPC service, and thus can now operate without privileges. Or in other words: there's now unprivileged systems-npsawn containers. Yay!) And that's all for today. See you soon for the 8th installment of this series. |
Gregory's Server
DDIs are supposed to carry dm-verity authentication information, i.e. every single access to them is typically cryptographically protected, and linked back to a set of signing keys maintained by the system (ideally in the kernel keyring). systemd uses DDIs for the system itself, for systemd-nspawn containers, for systemd portable services, for systemd-sysext system extensions, for systemd-confext configuration extensions and more.