Re: Some questions/thoughts on fs-verity

[Eric Biggers <ebiggers@kernel.org>]

Hi Colin,

On Fri, Nov 08, 2019 at 02:18:32PM -0500, Colin Walters wrote:
> 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.
> 

Can you take a step back and consider what security properties you're actually
trying to achieve?  In particular, be aware that if you just enable fs-verity on
a file but never actually compare the hash to anything, it provides integrity
only (detection of accidental corruption), not any authenticity protection.

In your pull request to OSTree (https://github.com/ostreedev/ostree/pull/1959),
I see a call to FS_IOC_ENABLE_VERITY.  But there's no corresponding call to
FS_IOC_MEASURE_VERITY to actually authenticate the file(s), nor is fs-verity's
built-in signature verification feature being used.  So this is integrity-only;
there's no protection against malicious modifications to the data on-disk.

I.e., fs-verity is really meant to be used as part of a userspace-driven
authentication policy.  It's not something that magically increases security by
itself.  That's partly why the scope of fs-verity is limited to file contents:
userspace can still authenticate other metadata if needed.

As for an attacker exploiting a filesystem bug, yes that is a big problem
currently in Linux.  However, gaining code execution via such a bug is a *bug*
and is patchable and mitigable, whereas gaining code execution by modifying
unauthenticated code stored on-disk is simply working as intended.

- Eric