On Thu, Feb 28, 2019 at 4:05 PM Mimi Zohar [off-list ref] wrote:

On Thu, 2019-02-28 at 15:13 -0800, Matthew Garrett wrote:

quoted

On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar [off-list ref] wrote:

quoted

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.

quoted

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?

quoted

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.

quoted

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.

quoted

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.