Some questions/thoughts on fs-verity

["Colin Walters" <walters@verbum.org>]

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!