Host Secure Boot with a linux host

[UlyssesOfEpirus]

With Secure Boot enabled in the host UEFI, how is it that installing vmware workstation on linux as the host, which changes the linux kernel, how is it that the modified linux kernel is still allowed to run? Doesn't Secure Boot mean that the kernel is signed and therefore fixed, with the signature in the UEFI firmware?

[dariusd · Accepted solution]

Installing Workstation does not modify the host kernel itself.  Workstation will build two additional kernel modules, and it's up to the existing kernel (unmodified and digitally signed) to decide whether or not to allow those modules to load.  Workstation cannot run without those two modules loaded.

Usually, when Secure Boot is enabled on the host, the host's Linux kernel will require a digital signature on any kernel modules that it is asked to load.  For current releases of Workstation, you'll need to manually sign the kernel modules yourself in order to be able to run Workstation on such a host OS.  Instructions for signing the kernel modules may be found here: "Cannot open /dev/vmmon: No such file or directory" error when powering on a VM (2146460) | VMware K...

Let me know if you have any further questions!

Cheers,

--

Darius

[UlyssesOfEpirus]

How come no such signing is needed in a windows host with Secure Boot?

[dariusd]

The difficulty with Workstation on Linux arises because of the broad variety of Linux distributions, which requires that the vmmon and vmnet kernel modules be built on the target system to ensure that they are compatible with that host system.  Windows has a stable kernel API, which enables VMware to build the Windows vmmon and vmnet drivers before we distribute VMware Workstation.  We then follow the usual Microsoft process for signing 3rd-party drivers, and distribute the signed drivers.

("Stable" here means "protected against incompatible change across new OS releases", which is an entirely different form of stability from the commonly-used meaning of "doesn't crash".  )

Essentially the lack of a stable Linux kernel API is what creates the requirement that the Linux kernel modules be built locally, and that creates a requirement that the kernel modules be signed locally too.  The stable Windows kernel API allows us to avoid that whole problem and distribute an already-signed kernel driver.  Apple also provides a stable kernel API too, which similarly allows us to distribute signed kernel extensions, avoiding that same problem for VMware Fusion for the Mac.

Cheers,

--

Darius

[UlyssesOfEpirus]

So any remote control malware that gains root access in the host can put its signature in the firmware with the following command and make a joke of Secure Boot versus traditional BIOS boot?

mokutil --import MOK.der

[dariusd]

No... the developers of this software stack have thought things through a bit more carefully than that. 

mokutil is not by itself able to simply add the certificate directly to the database...  It can only queue the cert for later addition to the database.  After running mokutil, the system must be rebooted.  At boot, the EFI shim bootloader will discover that a MOK request was queued, so it will launch the MOK Manager which will prompt the console operator to confirm the addition of the new certificate.  This process cannot be automated, and requires the manual confirmation of a physically-present user – or, more generally, requires access to the system console in the pre-boot environment, either by physical presence or via Service Processor based console redirection.  Malware cannot complete this step.  If a mokutil request is queued and no-one confirms the request at the console, the system will simply ignore the queued request and continue booting as it did before.

Here's a webpage (unrelated to VMware) which shows pictures of the enrollment process: ELRepo : SecureBootKey

I hope this helps to ease your concerns!

Cheers,

--

Darius

[UlyssesOfEpirus]

Is there a possibility that you end up bricking your computer by doing this?

[dariusd]

I can't see how this could realistically lead to bricking a computer.  Technically there is a small chance, but only if there is a catastrophic defect in either your host's UEFI firmware or the MOK manager.

Adding a new cert to the MOK database should be a very safe and trouble-free operation.

Deleting stuff from the MOK database would bring some risk of making the host a bit more difficult to recover (specifically, deleting a cert/key that's actually needed in order for the installed OS to boot successfully), but truly bricking it would seem very unlikely.  There would be a slightly increased risk during deletion if your host disallows access to its firmware user-interface or contains no facility to reset its boot configuration – I'm not immediately aware of any such systems, but I could imagine that something like a Microsoft Surface might be more constrained that your average PC.  Most regular PCs provide full access to the firmware user-interface for physically-present console users (as long as you have the "setup password", if one is configured), and those firmware user-interfaces will usually allow you to reset the Secure Boot configuration and allow booting an alternative operating system or recovery environment if necessary.  If you have concerns about this, refer to the documentation for your computer or motherboard for information on procedures for deactivating Secure Boot, resetting its Secure Boot configuration, or clearing its firmware configuration.

Cheers,

--

Darius

[UlyssesOfEpirus]

If I remove all internal hard drives and boot from a USB flash drive with a signed kernel of linux such as peppermintos, and with signed vmware kernel modules added by myself, can't malware that gets ROOT access in the host write itself to anywhere in the .squashfs file except the kernel files, and replace a frequently used command, and thus make itself permanent and just as bad as if it had modified an unsigned kernel?

[dariusd]

The same attack could be used against any initrd/initramfs, even just on a local hard disk.

You're right in that Secure Boot itself will not prevent such an attack, but each OS vendor can choose how their OS responds to Secure Boot being enabled.  The intent is that Secure Boot will be the first step in a "chain" of strong integrity verification using digital signatures.  The firmware would perform integrity checks on the bootloader.  The bootloader will check the kernel and its modules.  The bootloader can be extended to check that the integrity of the initramfs, and/or OS kernel security modules can be used to check the integrity of the files on the initramfs and/or in the main filesystem.

Just how many pieces of verification are done today will depend on your choice of OS, version and distribution.  I expect that many Linux distributions will steadily increase the amount of integrity checking in future releases as part of the "arms race" of attack and defense.  Microsoft Windows today is far ahead of most (all?) Linux distributions in terms of practical and usable support for "whole-stack" integrity-checking, rooted from the firmware through Secure Boot.

Cheers,

--

Darius

[UlyssesOfEpirus]

Would you recommend a libre (=true open source, no proprietary binaries) distro that does as many integrity checks as possible? But NOT one using SElinux for the integrity checks.

[dariusd]

It's really a personal choice, depending on what you need to do on your computer and what you perceive your attack/risk profile to be.  I wouldn't think "as many integrity checks as possible" is a good target to aim for, since that could practically be unlimited. 

I haven't deeply investigated the options for runtime integrity checking... I just know they exist.  This does link back to my earlier claim that Microsoft is far ahead in this space, since the average user doesn't need to investigate options... Installing Windows will automatically enable a robust integrity-checking system, configured at a level that will (hopefully) strike the right balance between security and functionality.  For the time being, us users of libre software will need to do our own investigation and make our own choices -- either in how to configure the OS you've chosen, or how to choose which OS distribution to use.

At some point, I'll either do the investigation myself (perhaps even using the source code), or install an OS whose vendor has done that investigation for me and enabled (or offered) a suitable level of integrity protection.

Cheers,

--

Darius