On Tue, Dec 14, 2021 at 4:20 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
