Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2021-12-03 at 22:08 +0000, Richard W.M. Jones wrote:
> I'm unclear about the threat model - this is an attacker who is
> someone able to overwrite single files (eg. /bin/ls) but cannot turn
> off the fs-verity system as a whole?
> 
> Also if RPM can update /bin/ls then surely an attacker who can widely
> compromise system files must also be able to update /bin/ls in the
> same way?

Once fs-verity is enabled for a given file (which, in the RPM case,
happens at package installation time), it cannot be disabled, and the
file becomes immutable. One can still rename() or unlink() it (and this
is indeed how rpm is able to replace files when upgrading packages),
but the actual contents cannot be altered.

Where is this useful? For example, fs-verity can help in the scenario
where an attacker has out-of-band access to the storage device (say,
they pull a hard drive from a colo'd server or a sdcard from an
embedded device, or they boot into a liveusb, or they access a VM image
directly from a host).

Let's say that happens, and the attacker changes a few blocks of
/bin/ls on the device to make it run nefarious code. When you boot your
system again, it would fail at exec() time because the Merkle tree
wouldn't match.

Let's say that instead the attacker mounts (or gains access to) your
filesystem, unlinks /bin/ls and replaces it wholesale with a new copy
(hence creating a new inode). The attacker doesn't have your signing
key, so they can't resign the file and enable fs-verity on it (they
could resign it with their own key, but unless they can then find a way
to load its cert into the kernel keyring it won't do much good). To
protect against this, you now have a few options:

- you could use a LSM to enforce that exec() can only happen on files
with valid fs-verity signatures; this would protect any binary
- you could use a launcher booted from secure storage (say, a dm-verity
volume, which could even be the initrd), and have this launcher perform
the verification; this of course only protects against binaries
executed from the launcher, but depending on your threat model it might
be enough

Like most security solutions, this isn’t a silver bullet and it’s not
something that in and of itself would necessarily prevent all possible
attacks. However, fs-verity can be a useful building block in a
defense-in-depth approach against specific attacks, depending on your
threat model.

Cheers
Davide

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux