On Thu, 2022-12-08 at 12:55 -0800, Eric Biggers wrote: > On Thu, Dec 08, 2022 at 10:43:01AM +0000, Luca Boccassi wrote: > > On Wed, 2022-12-07 at 19:35 -0800, Eric Biggers wrote: > > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > > > fsverity builtin signatures, at least as currently implemented, > > > are a > > > mistake and should not be used. They mix the authentication > > > policy > > > between the kernel and userspace, which is not a clean design and > > > causes > > > confusion. For builtin signatures to actually provide any > > > security > > > benefit, userspace still has to enforce that specific files have > > > fsverity enabled. Since userspace needs to do this, a better > > > design is > > > to have that same userspace code do the signature check too. > > > > > > That allows better signature formats and algorithms to be used, > > > avoiding > > > in-kernel parsing of the notoriously bad PKCS#7 format. It is > > > also > > > needed anyway when different keys need to be trusted for > > > different > > > files, or when it's desired to use fsverity for integrity-only or > > > auditing on some files and for authenticity on other files. > > > Basically, > > > the builtin signatures don't work for any nontrivial use case. > > > > > > (IMA appraisal is another alternative. It goes in the opposite > > > direction -- the full policy is moved into the kernel.) > > > > > > For these reasons, the master branch of AOSP no longer uses > > > builtin > > > signatures. It still uses fsverity for some files, but > > > signatures are > > > verified in userspace when needed. > > > > > > None of the public uses of builtin signatures outside Android > > > seem to > > > have gotten going, either. Support for builtin signatures was > > > added to > > > RPM. However, > > > https://fedoraproject.org/wiki/Changes/FsVerityRPM was > > > subsequently rejected from Fedora and seems to have been > > > abandoned. > > > There is also https://github.com/ostreedev/ostree/pull/2269, > > > which was > > > never merged. Neither proposal mentioned a plan to set > > > fs.verity.require_signatures=1 and enforce that files have fs- > > > verity > > > enabled -- so, they would have had no security benefit on their > > > own. > > > > > > I'd be glad to hear about any other users of builtin signatures > > > that may > > > exist, and help with the details of what should be used instead. > > > > > > Anyway, the feature can't simply be removed, due to the need to > > > maintain > > > backwards compatibility. But let's at least make it clear that > > > it's > > > deprecated. Update the documentation accordingly, and rename the > > > kconfig option to CONFIG_FS_VERITY_DEPRECATED_BUILTINSIG. Also > > > remove > > > the kconfig option from the s390 defconfigs, as it's unneeded > > > there. > > > > Hi, > > > > Thanks for starting this discussion, it's an interesting topic. > > > > At MSFT we use fsverity in production, with signatures enforced by > > the > > kernel (and policy enforced by the IPE LSM). It's just too easy to > > fool > > userspace with well-timed swaps and who knows what else. This is > > not > > any different from dm-verity from our POV, it complements it. I > > very > > much want the kernel to be in charge of verification and > > validation, at > > the time of use. > > Well, IPE is not upstream, and it duplicates functionality that > already exists > upstream (IMA appraisal). So from an upstream perspective it doesn't > really > matter currently. That's interesting that you've already deployed > IPE in > production anyway. To re-iterate my question at > https://lore.kernel.org/r/YqKGcdM3t5gjqBpq@sol.localdomain which was > ignored, > can you elaborate on why IPE should exist when IMA appraisal already > exists (and > already supports fsverity), and why IPE uses the fsverity builtin > signatures? Yes, IPE has been in production for years, it used in the feature described in the couple of minutes of Ignite starting at: https://www.youtube.com/watch?v=PO5ijv6WDv0&t=608s But I am not in the team that works on IPE, so I am not the best person to answer the first question, I do not have a good enough understanding of the implementation details of IPE/IMA to be able to say. I believe a new revision will be submitted soon, the submitter is the right person to ask that question. The second question is easy: because the kernel is the right place for our use case to do this verification and enforcement, exactly like dm- verity does. Userspace is largely untrusted, or much lower trust anyway. > And are you sure that X.509 and PKCS#7 should be used in a new > system? These > days, if you go through any sort of crypto or security review, you > will be told > not to use those formats since they are overly complex and prone to > bugs. Yes. We need to use the same mechanism as dm-verity, and in fact many more systems, already make use of. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
