On Tue, Dec 14, 2021 at 4:20 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Tue, Dec 14, 2021 at 08:08:19PM +0100, Fabio Valentini wrote:
> I thought fsverity was about determining at runtime that the
system
> has not been tampered with? But if somebody who has (physical) access
> to the device can just ... move verified files out of the way and put
> their own (unverified) files there (which then apparently does not
> trigger red warning signs?) - doesn't that defeat the whole purpose of
> enabling fsverity?
That's a good question. fs-verity and dm-verity share the same
underlying concept (merkle trees and signature verification by the
kernel). So this raises the question that you asked… which can also be
phrased as "why would you even use fs-verity, if you can do dm-verity"?
dm-verity presents a read-only block device. It can't be modified once created.
fs-verity works at the VFS layer. The block device and file system
remain read-write capable, only the fs-verity enabled file contents
are read-only. Also, fs-verity only really provides integrity checking
in an efficient manner, with an optional mechanism for user space to
enforce authentication - the kernel doesn't do this. A further option
for user space is auditing.
There is this dance in computer security where you're constantly
plugging holes, looking for holes, but also assuming certain holes are
definitely filled. It might seem like a contradiction. But of course
we say physical access means the system is compromised, so you have to
assume that hole is filled or all bets are off. Here you have to
assume enough of user space is not compromised enough that you can
trust that the fs-verity mechanisms can be used (create and verify),
and the reason why you're using this regime is to make certain
modifications impossible without detection so that the system doesn't
become compromised, or at least compromised in silent fashion.
fs-verity does not completely provide a secure and closed system, it's
just one aspect of creating a more secure system.
I'd go so far as to say it takes some esoteric knowledge to understand
that this is only a "probably important small thing", and not a
"critical big thing", to do. This is a few years old, 2018, but it
discusses some of the confusing points when fs-verity was merged.
https://lwn.net/Articles/763729/
Chris Murphy
My understanding it the following: fs-verity originated in the
Android
world where you can have an unprivileged process downloading a file,
e.g. a jar. This unprivileged process manages the download, but the
file is only trusted and executed when it has a matching signature
from some central authority. The file contains the whole app,
including all resources, so there is no question of other unverified
files being used by the app. And the file can be large enough that
it's practical to do chunked verification, since checksumming the whole
file on first use would be slow.
We don't really have the same considerations: the download process
has full privileges, and the download is exploded into individual files,
and more importantly, unpackaged files are also used.
--
Chris Murphy