Does enabling and configuring Secure Boot offer no additional security benefit in Ubuntu?

Question

Is the text below from the website of The National Cyber Security Centre, UK true?

Whilst Secure Boot hardware can verify the first step of the boot chain, Ubuntu does not continue verifying the booting system, so enabling and configuring Secure Boot offers no additional security benefit.

score 0 · Answer 1 · answered Oct 01 '17 at 23:24

0

That is indeed true. On Windows, secure boot can offer additional benefits, as noted by NCSC:

The Early Launch Anti-Malware (ELAM) driver provides signature checking for known bad drivers on ELAM compliant systems that are configured to use Secure Boot.

...

The Windows 10 Secure Boot process (on supported and correctly configured hardware) alerts a user when an attempt to subvert the security controls has taken place. It is important that users know how to identify and respond to this alert.

Neither feature is available on Ubuntu that I am aware of.

answered Oct 01 '17 at 23:24

muru

197,895
55
485
740

Kernel drivers need to be signed, or they won't load. Ubuntu also tells the user if there's a problem... granted... in a very cryptic fashion... – heynnema Oct 01 '17 at 23:34
@heynnema not in the ELAM sense, I think - drivers merely need to be signed properly; there's no checking to see if a driver signature is from a set of known bad ones, AFAIK. – muru Oct 01 '17 at 23:36
@muru -- although Windows does have those extra features, ubuntu is less prone to those attacks. So I guess the question is: Does Ubuntu's inherent security make the extra features of Win10 unneeded? – ravery Oct 02 '17 at 02:52

ob2 · Answer 2 · 2017-10-01T23:40:25.580

0

This is true, Secure Boot over UEFI only checks for a signed boot firmware (file placed on a FAT32 partition used to run a boot loader), but it seems that a check of signed drivers can be done as well, but I never heard of drivers signing within Ubuntu while Microsoft systems does it. The rest of the file system is not signed for sure.

Some information here

edit : I founded the linux signed package in Ubuntu repository, means that drivers are signed as well.

edited Oct 01 '17 at 23:40

answered Oct 01 '17 at 23:29

ob2

3,553

Standard kernel drivers come signed in Ubuntu, otherwise none of them would load if Secure Boot was enabled. – heynnema Oct 01 '17 at 23:35
That right, just founded linux signed image in Ubuntu repository, thanks for info ! https://packages.ubuntu.com/trusty/kernel/linux-signed-image-generic – ob2 Oct 01 '17 at 23:38
So if the kernel and the kernel modules are signed and checked, the answer should start with "this is wrong"... – pim Oct 02 '17 at 06:52

score 0 · Answer 3 · answered Oct 10 '17 at 13:59

Ubuntu's Secure Boot support has changed over time, and the quote you've provided is outdated. Broadly speaking, there are several stages at which validation might occur:

Validation of the boot loader -- This is the limit of what Secure Boot, per se, does. Secure Boot prevents the UEFI from launching unsigned (or improperly signed) binaries, and that's basically it. Under EFI, boot loaders are EFI binaries, so Secure Boot stops them from launching if they aren't signed. A boot loader, however, is designed to launch a kernel, which is not an EFI binary, so by itself, Secure Boot cannot block the launch of an unsigned kernel if the boot loader is designed to permit it. (There are some caveats and exceptions relating to technical details, though.) Thus, at this level, Secure Boot can prevent the boot loader from being compromised, but it can't prevent subsequent parts of the software stack from being compromised.
Validation of the kernel -- To improve security further, the kernel should be validated. The last I heard (which was two or three years ago), the stock GRUB did not validate the kernel in any way. Thus, if you were to use a stock GRUB, it would happily launch any kernel you fed it. Ubuntu through at least version 12.04 used a GRUB that worked in this way. Modified GRUB binaries that require a signed kernel are available, and are used by many distributions. I don't recall if Ubuntu 14.04's GRUB required a signed kernel. Ubuntu 16.04's GRUB definitely requires a signed kernel, at least with its default configuration. Also, since at least version 12.04, Ubuntu has provided kernels that were signed with Secure Boot keys, and that could therefore be launched with a boot loader that did this validation. Thus, by swapping out the stock GRUB, even Ubuntu 12.04 could be configured to require a signed kernel.
Validation of kernel modules -- Linux kernels can load kernel modules, and if a kernel is signed but loads a malware-infested kernel module, the signed state of the main kernel is meaningless. Although I'm not 100% sure of whether Ubuntu 14.04 required a signed kernel, I am reasonably confident that Ubuntu 14.04 did not require signed kernel modules. This has changed with Ubuntu 16.04. This change has been an inconvenience to people who want to use third-party proprietary drivers, such as those for VirtualBox or video drivers for ATI/AMD or Nvidia chips. These driver modules are not signed by Canonical, which necessitates adding a Machine Owner Key (MOK) ans self-signing the modules, if Secure Boot is to be kept enabled.
Validation of user-space binaries -- Once the kernel has loaded, it launches user-space binaries -- everything from bash to Web browsers and word processors. In principle, a kernel could require these binaries to be signed. In practice, I don't know of any support for such a signing requirement in Linux. Such a requirement would be quite onerous, particularly for software developers or anybody who wants to run binaries from third parties.

In addition to these four major levels of (potential) verification, there are several twists, in-between levels, exceptions, etc. For instance, a kernel can include an EFI stub loader, which turns the kernel into its own boot loader, thus blurring the line between steps 1 and 2. I've also seen kernels that refuse to launch if they're launched from a boot loader that doesn't do Secure Boot validation, which turns around the requirement of step #2. In principle, validation beyond the boot loader could use a mechanism other than Secure Boot keys. In practice, in the Linux world, Secure Boot keys are used through step #3; however, it's my understanding that the kernel provides its own code to validate kernel modules (step #3), so technically the Secure Boot code in the UEFI is not involved past step #2. (I've never investigated this in depth, though, so I might be mistaken about this detail.)

Also, I've focused on LTS releases in my descriptions above. Some of the security changes may have been introduced in interim (non-LTS) releases; I don't recall the details.

As noted, Ubuntu has been increasing its level of validation requirements over time. The quote you've provided was accurate for Ubuntu 12.04, and perhaps 14.04, but not 16.04 -- at least, not with a default configuration with Secure Boot enabled in the firmware. (You could of course swap out Ubuntu's GRUB for an older version or another boot loader that does no Secure Boot validation at all.) For some applications, finer details, like code reviews of validation code, may be important. If you're working in a high-security environment (like a bank, defense contractor, certain government agencies, etc.), you should definitely rely on your own employer's security department, security contractors, etc., rather than advice from random strangers on a Web forum.

Does enabling and configuring Secure Boot offer no additional security benefit in Ubuntu?

3 Answers3