Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2018-03-15 at 14:16 +0800, joeyli wrote:
> On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote:
> > 
> > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote:
> > > 
> > > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote:
> > > > 
> > > > 
> > > > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote:
> > > > > 
> > > > > 
> > > > > This patch adds the logic for checking the kernel module's
> > > > > hash base on blacklist. The hash must be generated by sha256
> > > > > and enrolled to dbx/mokx.
> > > > > 
> > > > > For example:
> > > > > 	sha256sum sample.ko
> > > > > 	mokutil --mokx --import-hash $HASH_RESULT
> > > > > 
> > > > > Whether the signature on ko file is stripped or not, the hash
> > > > > can be compared by kernel.
> > > > 
> > > > What's the use case for this?  We're already in trouble from
> > > > the ODMs for the size of dbx and its consumption of the
> > > > extremely limited variable space, so do we really have a use
> > > > case for adding module blacklist hashes to the UEFI variables
> > > > given the space constraints (as in one we can't do any other
> > > > way)?
> > > > 
> > > 
> > > The dbx is a authenticated variable that it can only be updated
> > > by manufacturer. The mokx gives a flexible way for distro to
> > > revoke a key or a signed module. Then we don't need to touch shim
> > > or bother manufacturer to deliver new db. Currently it doesn't
> > > have real use case yet. 
> > > 
> > > I knew that the NVRAM has limited space. But distro needs a
> > > backup solution for emergency.
> > 
> > I wasn't asking why the variable, I was asking why the mechanism.
> > 
> > OK, let me try to ask the question in a different way:
> > 
> > Why would the distribution need to blacklist a module in this way?
> >  For
> 
> This way is a new option for user to blacklist a module but not the
> only way.

So this is for the *user* not the distribution?

>  MOK has this ability because shim implements the mokx by signature
> database format (EFI_SIGNATURE_DATA in UEFI spec). This format
> supports both hash signature and x.509 certificate.
> 
> > 
> > the distro to execute the script to add this blacklist, means the
> > system is getting automated or manual updates ... can't those
> > updates just remove the module?
> > 
> Yes, we can just remove or update the module in kernel rpm or kmp.
> But user may re-install distro with old kernel or install a old kmp.
> If the blacklist hash was stored in variable, then kernel can prevent
> to load the module.
> 
> On the other hand, for enrolling mokx, user must reboots system and
> deals with shim-mokmanager UI. It's more secure because user should
> really know what he does. And user can choice not to enroll the hash
> if they still want to use the module.

OK, so now the use case is the user needs to roll back but doesn't want
a module to load ... I've got to say that in that case I'd just remove
it before reload.

> > The point is that module sha sums are pretty ephemeral in our model
> > (they change with every kernel), so it seems to be a mismatch to
> > place them in a permanent blacklist, particularly when we have very
> > limited space for that list.
> > 
> Normally we run a serious process for signing a kernel module before
> shipping it to customer. The SUSE's "Partner Linux Driver Program”
> (PLDP) is an example. So the module sha sums are not too ephemeral.

Ephemeral isn't about the signing process it means that the sum is
short lived because every time you create a module for a specific
kernel its sum changes (because of the interface versioning) so your
blacklist only applies to one module and specific kernel combination.
 Once you compile it for a different kernel you need a different
blacklist sum for it.

James