On Wed, 19 Jun 2019 at 15:57, Francois Ozog francois.ozog@linaro.org wrote:
Hi
I was tasked to come back to Linaro TSC with an answer on Linaro and kernel lockdown for UEFI SecureBoot, hence the call for feed back.
So I did some research... The kernel lockdown does not seem to be a full consensus yet: https://news.ycombinator.com/item?id=16761827
I agree with Linus
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1654795.html:
we should distinguish UEFI SecureBoot and how to achieve a highly secured Operating System runtime environment.
Decoupling the enable/disable decision for kernel lockdown from the UEFI secure boot status is, I think, already widely agreed upon. Certainly the latest versions of the lockdown patchset already implement this decoupling ( https://lwn.net/Articles/784674/ ).
- UEFI SecureBoot: boot chain trust
My understanding is that UEFI SecureBoot ensures that the booted UEFI payload is trusted. Should the UEFI payload (a Linux OS) not be that secure it is irrelevant to the UEFI SecureBoot itself.
- Trustable Linux system
A trustable Linux system is UEFI SecureBoot loaded and make addition precautions to avoid attacks and attacks to the boot chain. If we think of a highly secured Linux, the kernel lockdown is certainly highly desirable but just as many other aspects:
- iommu must be enabled to protect against DMA attacks
- sysfs needs to be cleaned (access rights are not tight enough)
- debugfs need to be banned (problem: some production control operations
are wrongly in debugfs) -SE Linux
- IMA
- ...
In my view, we shall not mix the goal and the means to achieve the goal.... For instance, kernel lock down prevents iopl system call which prevents UIO and UIO enabled DPDK drivers. A vendor may evaluate that the security level achieved without kernel lockdown is in line with its objectives to achieve a trustable Linux system: loadable modules disabled by the kernel, kernel embedded initramfs, IMA...
If the vendor intends to get this *right* I think they would be extremely foolish to overlook the knowledge already embedded in the lockdown patchset. Lockdown will probably never be perfect but ignoring this significant body of battle tested and well documented work sounds like madness to me.
Daniel.
As a result, UEFI SecureBoot to secure the boot chain combined with selected Linux hardening can achieve a Trustable Linux System.
As per LEDGE both are highly important I would say that 1) does not need 2) to be complete.
The way to achieve 2) is project dependent. The LEDGE RP will need kernel lockdown because we will allow loadable modules. SoC vendors deriving a product out of LEDGE RP, may take different provisions as per customer projects, in particular, they may derive a version without lockdown but still trustable.
There is an additional twists to this.
UEFI SecureBoot does not mandate Microsoft signed keys. But if you use Microsoft keys, I was warned that Microsoft may revoke certificates for non locked down systems. This warning illustrate the absolute need for independence related to UEFI SecureBoot: I can't imagine a system in Europe (particularly in military) prevented to boot because Microsoft revoked a certificate!!!
Cheers
FF
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture