[RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

[Luis R. Rodriguez]

On Mon, Apr 02, 2018 at 05:42:22PM -0700, Andy Lutomirski wrote:
> On 11/10/2017 01:02 PM, Mimi Zohar wrote:
> > If the kernel is locked down and IMA-appraisal is not enabled, prevent
> > loading of unsigned firmware.
> 
> > diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig
> > new file mode 100644
> > index 000000000000..d6aef6ce8fee
> > --- /dev/null
> > +++ b/security/fw_lockdown/Kconfig
> > @@ -0,0 +1,6 @@
> > +config SECURITY_FW_LOCKDOWN
> > +	bool "Prevent loading unsigned firmware"
> > +	depends on LOCK_DOWN_KERNEL
> > +	default y
> > +	help
> > +	  Prevent loading unsigned firmware in lockdown mode,
> 
> Please be honest about what this does.  This option makes your system
> useless if you don't use IMA-Appraisal and it offers a particular security
> benefit if you do you IMA-Appraisal.  How about making it depend on
> IMA-Appraisal?  Change the name to SECURITY_ONLY_LOAD_IMA_APPRAISED_FIRMWARE
> and adjust the text accordingly, please.

Mimi is on vacation right now so I'll address this.

All the above makes sense, but just keep in mind the patch was posted just as
an illustration of how IMA *can* live up to the original intent proposed by
David Howells on kernel lockdown. David's old kernel lockdown documentation
stipulated that a requirement was to also prevent loading unsigned firmware.

Does the kernel lockdown documentation still have a section indicating signed
firmware is a requirement? Or was that removed in the end?

Mimi's RFC was at a time when we still had on our roadmap the prospect of
adding generic signed firmware support into Linux. Mimi's point and RFC patch
was an illustration then on how IMA users can already meet these assumed
requirements on 'kernel lockdown', and that if we used a micro LSM hook this
could be easily managed, given the firmware signing support we intended on
adding would not be needed for IMA systems. Her point was that with IMA you can
already meet the definition and IMA systems would not have to wait for "generic
firmware signing" to be merged.

The biggest thing which has changed since then is that we decided to *not*
support or streamline generic firmware signing (non-IMA) for now for a few
reasons [0] [1] which are important to re-iterate as these are easy to forget,
and AFAICT not documented anywhere.

One was that my own requirement for it was already done -- cfg80211 already
open codes firmware signing checking on its own through the new
CONFIG_CFG80211_REQUIRE_SIGNED_REGDB thereby also not requiring CRDA anymore,
the userspace component which used to read the signed regulatory database and
then send regulatory content to the wireless subsystem. So CRDA is no longer
needed if you enable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB.

Second, is is that the whole UEFI movement pushed hardware vendors to start
embracing requiring signed firmware on peripherals themselves. So a lot of
hardware these days *does* do firmware signing already and a generic kernel
firmware signing facility would then just make us do double work then. There
are exceptions and there are a few reasons for this. For instance USB devices
are not allowed to pee on random memory (thanks for the analogy Alan!), so
not all USB devices have support for checking their own firmware signature.
This is one reason also why why some operating systems do not allow users
to use random USB devices. If companies *really* need to vet for these they
have a few options, one is to use IMA, the other is to have the driver open
code the firmware signing component just as we did with cfg80211 through the
new CONFIG_CFG80211_REQUIRE_SIGNED_REGDB. If we end up later with enough
open coded firmware checking users we can later revisit adding a generic
firmware signing facility.

Third is that there is no strong evidence of any security issue with having
firmware in /lib/firmware not be signed. I can attest to this, in my research
of all the history of this, I cannot find a single incident which calls bloody
murder for unsigned firmware.  There are concerns and known backdoors on
firmware for storage drives for instance, but these are not /lib/firmware
files, for instance. If you also consider the second reason above, it may also
help explain why perhaps there is also any serious threat on this front.
Granted, there are known cases know of a third party using some signing key to
sign malicious firmware and using that to exploit an OS, but if they did that
and we trusted each vendor signing key as well we'd be just as vulnerable.

Fourth, if you want signed /lib/firmware, you might want signed binaries, and
if you want signed binaries, we already have IMA.

So.. until there is no real strong reason to support and maintain a generic
firmware signing mechanism, no need to add it. We can wait for the open coded
boom, and if that really does happen we'll revisit later.

So the kernel lockdown definition may want to revise all the above, review its
documentation and if the "firmware signing" aspect is still there, update it
somehow to reflect or ignore the above.

If we want to keep "signed firmware" as a requirement for "kernel lockdown"
then we have no option to also amend the definition I think to consider signed
executables, and imply or recommend the use of IMA. If the assumption is that
peripherals or drivers all have hardware firmware signing support and are OK
with random USB gadgets, then perhaps we are OK in removing (if its not already
removed) the "signed firmware" requirement from the "kernel lockdown"
definition, and the concept of signed firmware or IMA can live on as additional
effort for now.

However, *iff* we *really* want to push again for generic "signed firmware", we
want a good justification for it considering all the above. To be fair I'll
note that I don't recall a super strong justification for signed modules back
in the day, other than Rusty saying 'its happening', 'its being merged', and that
some companies wanted it.  I think we do have the case of companies wanting signed
firmware in this case as well... however the issue is the foundations may be on
a warm fuzzy feeling only, and a big difference is that with modules you don't
have peripherals checking for the signed bits, with firmware we do have this
practice growing these days.

If we *do* end up moving forward with generic "signed firmware" later though,
the architecture for it would be through a micro LSM as Mimi suggested in this
patch, and it would whitelists IMA. The patch would also need to be updated to
whitelist the new CONFIG_CFG80211_REQUIRE_SIGNED_REGDB and any other open coded
signed firmware bits which may get merged later.

  Luis

> > +/**
> > + * fw_lockdown_read_file - prevent loading of unsigned firmware
> > + * @file: pointer to firmware
> > + * @read_id: caller identifier
> > + *
> > + * Prevent loading of unsigned firmware in lockdown mode.
> 
> That comment gives a highly misleading impression of what this function
> does.
> 
> > + */
> > +static int fw_lockdown_read_file(struct file *file, enum kernel_read_file_id id)
> 

-- 
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html