It's clear that the Linux kernel is widely deployed with things like dm-verity devices where the user of the device isn't root. There are great security properties from this in ensuring malicious code (compromised apps/OS) can't persist, and what Google is doing with ChromeOS/Android is a good example. However, for cases where the user *is* root (or, like me as an OS vendor trying to support an OS where the user can be root), dm-verity comes with a whole host of restrictions and issues. This was noted in the earlier fs-verity discussions. Among other ones, simply trying to commit to a partition size beyond which the trusted OS cannot grow is seriously ugly. Another example here is with ostree (or other filesystem-level tools) it's easy to have *three* images (or really N) so that while you're downloading updates you don't lose your rollback, etc. I'm excited about the potential of fs-verity because it's so much more *flexible* - leaving aside the base OS case for a second - for example fs-verity is even available to unprivileged users by default, so if the admin has at least enabled the `verity` flag, if a user wanted to they could enable fs-verity for e.g. their `~/.bashrc`. That's neat! However, this gets into some questions I have around the security properties of fs-verity because - it only covers file contents. There are many problems from this: - Verifying directories and symlinks is really desirable too; take e.g. /etc/systemd/system - I want to verify not just that the unit files there are valid, but also that there's no malicious ones. - Being able to e.g. `chown root:root` `chmod u+s` a fs-verity protected binary is...not desired. - Finally, taking the scenario of a malicious code that has gained CAP_SYS_ADMIN and the ability to write to raw block devices, it seems to me that the discussions around "untrusted filesystems" (https://lwn.net/Articles/755593/) come to the fore. In contrast because dm-verity is sealing up *everything* at the fs level, all of the above are avoided. But it's obviously far less flexible... (This discussion of course mirrors fs-crypt versus dm-crypt too) I guess my concrete question here is: Are there any plans around extending fs-verity to address any of this? Which I know given the current developers probably mostly boils down to a future Android/ChromeOS architecture question, but I think fs-verity has the potential to be used beyond just that if it isn't already. Would love to discuss with any other distributions/update system developers etc. that are also looking at fs-verity!
|