| Message ID | 20180824161642.1144-1-ebiggers@kernel.org |
|---|---|
| Headers | show |
| Series | fs-verity: filesystem-level integrity protection | expand |
On Fri, 2018-08-24 at 09:16 -0700, Eric Biggers wrote: [...] > Since fs-verity provides the Merkle tree root hash in constant time and > verifies data blocks on-demand, it is useful for efficiently verifying > the authenticity of, or "appraising", large files of which only a small > portion may be accessed -- such as Android application (APK) files. It > can also be useful in "audit" use cases where file hashes are logged. > fs-verity also provides better protection against malicious disk > firmware than an ahead-of-time hash, since fs-verity re-verifies data > each time it's paged in. [...] > Feedback on the design and implementation is greatly appreciated. Hi, I've looked at the series and the slides linked form the recent lwn.net article, but I'm not sure how fs-verity intends to protect against malicious firmware (or offline modification). Similar to IMA/EVM, fs- verity doesn't seem to include the name/location of the file into it's verification. So the firmware/an attacker could replace one fs-verity- protected file with another (maybe a trusted system APK with another one for which a vulnerability was discovered, or /sbin/init with /bin/sh). Is the expected root hash of the file provided from somewhere else, so this is not a problem on Android? Or is this problem out-of-scope for fs-verity? For IMA/EVM, there were patches by Dmitry to address this class of attacks (they were not merged, though): https://lwn.net/Articles/574221/ Thanks, Jan [1] https://events.linuxfoundation.org/wp-content/uploads/2017/11/fs-ve rify_Mike-Halcrow_Eric-Biggers.pdf
Hi Jan, On Fri, Aug 31, 2018 at 10:05:23PM +0200, Jan Lübbe wrote: > On Fri, 2018-08-24 at 09:16 -0700, Eric Biggers wrote: > [...] > > Since fs-verity provides the Merkle tree root hash in constant time and > > verifies data blocks on-demand, it is useful for efficiently verifying > > the authenticity of, or "appraising", large files of which only a small > > portion may be accessed -- such as Android application (APK) files. It > > can also be useful in "audit" use cases where file hashes are logged. > > fs-verity also provides better protection against malicious disk > > firmware than an ahead-of-time hash, since fs-verity re-verifies data > > each time it's paged in. > [...] > > Feedback on the design and implementation is greatly appreciated. > > Hi, > > I've looked at the series and the slides linked form the recent lwn.net > article, but I'm not sure how fs-verity intends to protect against > malicious firmware (or offline modification). Similar to IMA/EVM, fs- > verity doesn't seem to include the name/location of the file into it's > verification. So the firmware/an attacker could replace one fs-verity- > protected file with another (maybe a trusted system APK with another > one for which a vulnerability was discovered, or /sbin/init with > /bin/sh). > > Is the expected root hash of the file provided from somewhere else, so > this is not a problem on Android? Or is this problem out-of-scope for > fs-verity? > > For IMA/EVM, there were patches by Dmitry to address this class of > attacks (they were not merged, though): > https://lwn.net/Articles/574221/ > > Thanks, > Jan > > [1] https://events.linuxfoundation.org/wp-content/uploads/2017/11/fs-ve > rify_Mike-Halcrow_Eric-Biggers.pdf Well, it's up to the user of fs-verity. If you know that, say, /bin/sh is supposed to have a fs-verity file measurement of sha256:01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b, then you can just check that. Or, after IMA support is added, users will be able to configure the fs-verity measurements to go into the IMA measurement log and/or audit log, just regular file hashes. Those records include both the file path and hash. On the other hand, if the policy you want to enforce is just that a particular file is using fs-verity and that its hash has been signed by a particular key, then indeed, if there are multiple hashes that were signed with that key, an attacker can replace the contents with a different signed contents. But that's not really fs-verity's fault; it's really the type of policy that the user chose to use on top of it, as part of their overall system security architecture. Yes, the initial plan for Android APK verification is to just use that type of policy, probably using the in-kernel signature verification support included in patch 07/10. So it will therefore have that limitation. Still, it will be a massive improvement over the status quo where attackers can make arbitrary changes to APK files post-installation, e.g. to persistently inject arbitrary malware. It will also be possible to improve the security properties of APK verification in the future by doing additional checks, such as optionally including additional file metadata in the fs-verity measurement (fs-verity's design allows for this; they can be added as authenticated extensions), or even simply checking for the correct metadata from trusted userspace code running in the /system partition. Or perhaps the trusted userspace code could download the expected fs-verity measurement of the APK from the app store given the app name. There are lots of options. But we have to start somewhere, and fs-verity is a tool that seems to be needed in any case. - Eric