Gregory's ServerAnd 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.
|
3 comments
 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. |
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.