On Thu, Feb 28, 2019 at 4:05 PM Mimi Zohar <zo...@linux.ibm.com> wrote: > > On Thu, 2019-02-28 at 15:13 -0800, Matthew Garrett wrote: > > On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar <zo...@linux.ibm.com> wrote: > > > Where/when was this latest version of the patches posted? > > > > They should have followed this, but git-send-email choked on some > > reviewed-by: lines so I'm just trying to sort that out. > > I'm a little perplexed as to why you would send a pull request, before > re-posting the patches with the changes for review.
They should be there now. There's no substantive change to the patches, other than having dropped a few from the series. > > It's a little more complicated than this. We can't just rely on IMA > > appraisal - it has to be based on digital signatures, and the existing > > patch only made that implicit by enabling the secure_boot policy. > > Right, which is the reason the IMA architecture specific policy > requires file signatures. [1][2] The current patches seem to require ima signatures - shouldn't this allow ima digests as long as there's an evm signature? > > I > > think we do want to integrate these, but there's a few things we need > > to take into account: > > > > 1) An integrated solution can't depend on xattrs, both because of the > > lagging support for distributing those signatures but also because we > > need to support filesystems that don't support xattrs > > That's not a valid reason for preventing systems that do use IMA for > verifying the kexec kernel image signature or kernel module signatures > from enabling "lock down". This just means that there needs to be > some coordination between the different signature verification > methods. [1][2] I agree, but the current form of the integration makes it impossible for anyone using an IMA-enabled kernel (but not using IMA) to do anything unless they have IMA signatures. It's a problem we need to solve, I just don't think it's a problem we need to solve before merging the patchset. > > 2) An integrated solution can't depend on the current secure_boot > > policy because that requires signed IMA policy updates, but > > distributions have no way of knowing what IMA policy end users require > > Both the "CONFIG_IMA_APPRAISE_REQUIRE_KEXEC_SIGS" and the IMA > architecture policy rules persist after loading a custom policy. > Neither of them require loading or signing a custom policy. The previous version of the lockdown patchset sets the secure_boot policy when lockdown is enabled, which does require that any custom policy be signed. > > In any case, I do agree that we should aim to make this more > > reasonable - having orthogonal signing code doesn't benefit anyone. > > Once there's solid agreement on that we can extend this support. > > > > Having multiple signature verification methods is going to be around > for a while. The solution is to coordinate the signature verification > methods, without requiring both types of signatures. [1][2] Agree, and once we have a solution to this we should integrate that with lockdown. I don't think merging this first makes that any harder. Importantly, this version of the patchset doesn't enable lockdown automatically unless explicitly configured to do so, which means you can build a lockdown kernel without interfering with IMA.
