Включить secure boot linux

Enabling secure boot and full disk encryption on Ubuntu Core

In this tutorial, we will show the simplicity of the process of enabling Full Disk Encryption (FDE) and Secure Boot on Ubuntu Core on platforms with Trusted Platform Module (TPM) support. A quick introduction for understanding the concepts and a simple walk through the process of preparing and flashing an Intel NUC image, will be followed.

FDE and Secure Boot are key security features which have been incorporated into Ubuntu Core 20 release, complementing the out-of-the-box security characteristics already available in previous versions.

Bear in mind, Ubuntu Core is production-friendly, not necessarily developer-friendly. We recommend you use Ubuntu Core for “fire and forget” purposes where you won’t want to iterate on the software.

With Ubuntu Core, you are able to execute remote updates and patches for your appliances and devices, but for development and prototyping, we recommend Ubuntu Server. Let’s start!

What you’ll learn

What you’ll need

• An Ubuntu SSO account with an SSH key
• An Intel NUC with BIOS updated to the latest version (update instructions)
• 2 USB 2.0 or 3.0 flash drives (2GB minimum)
• A monitor with an HDMI interface
• A Mini HDMI to HDMI cable
• A USB keyboard and a mouse
• A monitor with VGA or HDMI interface
• A VGA or HDMI cable
• A network connection with Internet access
• An Ubuntu Desktop 20.04.1 LTS image
• An Ubuntu Core image

2. Understanding FDE and Secure Boot

Fundamentals of FDE

Ubuntu Core 20 uses full disk encryption (FDE) whenever the hardware allows, protecting both the confidentiality and integrity of a device’s data when there’s physical access to a device, or after a device has been lost or stolen.

Built-in FDE support requires both UEFI Secure Boot and TPM (Trusted Platform Module) support, but its implementation in Ubuntu Core is generic and widely compatible to help support a range of hardware. TPM-based FDE seals the FDE secret key to the full EFI state, including the kernel command line, which is subsequently unsealed by the initrd code in the secure-boot protected kernel.efi at boot time.

For further reading about FDE, you can find the key aspects here and more extensive documentation can be found here.

Fundamentals of Secure Boot

The boot process can be detrimental to computers, if not secured. This is the case because booting is the initial stage of a computing cycle. Kernel, hardware peripherals, and user space processes are initiated at boot. Therefore, a vulnerability in boot firmware can have cascading effects on the entire system.

Secure Boot is an operation booting mode which denies the execution of any software which is neither signed nor certified, assuring software integrity.

You can read the full Secure Boot story here.

Understanding model assertion

Using FDE and Secure Boot features in Ubuntu Core is as simple as selecting the right image to flash. Ubuntu Core does the rest for you on the booting process.

Although it is possible to build your own Ubuntu Core images, the easiest starting point for any user is to make use of pre-built images. Latest stable images can always be found here.

In either case, each image has an associated model assertion file, a text-based document that contains the fundamental definition of the image for a specific device. It describes what the system image includes and is signed by the brand account owning the device definition.

There are two key fields in the model assertion file related to FDE and Secure Boot:

• grade: It indicates the overall degree of security of the image
• storage-safety: It reflects the preferred mode of filesystem encryption

Grade and Storage-safety are tightly coupled, and their combination along with the platform’s HW TPM support, results in the following operation modes:

• Encrypted: Filesystem gets encrypted on first boot.
• Unencrypted: Filesystem is not encrypted.
• Error output: The image doesn’t boot. An error message is generated.
• Invalid: It’s not possible to generate an image with such combination.

Which are summarized in the following table:

More detailed information on image building and model assertion files can be found in the Ubuntu Core Documentation.

3. Selecting the image

As described in the previous section, using FDE and Secure Boot is just a matter of choosing the right image for your platform.

Prebuilt images

If you are using an standard platform with HW TPM support, such as an Intel NUC, you will probably want to use a prebuilt image, following the steps below:

1. Download the latest image from here
2. Download also the model assertion file and make sure the right combination of grade and storage-safety is set for your platform according to the previous table

Note: For Intel NUC platforms, the pre-built image enables FDE and Secure Boot by default. This can be checked in the model assertion file [line to the assertion file URL].

Custom images

If you are using your own board or if a custom self-built image is going to be used, it must be ensured that the combination of platform (HW TPM support) + grade + storage-safety, makes it possible to have FDE and Secure Boot support. The steps below must be followed:

1. Check that your board has HW TPM support
2. Generate a new model assertion file according to this instructions setting the appropriate grade and storage-safety options

4. Flashing the image

Once you have selected the image, the process of flashing and first configuration of the board does not differ from the standard flashing process. Intel NUC flashing process can be found here.

5. Wrapping up

Full Disk Encryption and Secure Boot are key features of Ubuntu Core. They don’t need to be specifically enabled on a configuration or on-boarding process, they are out-of-the-box features which will be applied if the combination of platform and image model assertion allows it.

In summary, security is no longer an option but a compulsory feature with Ubuntu Core when hardware TPM is available on the platform, making the process as simple as installing the image on the device.

Further reading

Источник

How to enable Secure Boot without issue?

I read here that it is essential to have Secure Boot enabled: However I find that when I enable Secure Boot, it changes it so that systems can boot with UEFI boot, but not Legacy, it also disables CMS. However, when I then try to boot my system, I get 3 different start things that I can boot from:

- ATAPI CD1: PLDS DVD-RW DS8A8SH - ATA HDD0: TOSHIBA MK5065GSX > PCI LAN - LAN(3C970E7102F6) -IPv4 - LAN(3C970E7102F6) -IPv6 

But no matter which of them I choose, I just get back to that screen and cannot boot, then the only way is to go to the other tab and select Setup , go back into BIOS, and disable Secure Boot, and then say that both Legacy and UEFI are supported in the Setup options (as just disabling Secure Boot does not work). So I am assuming that my current and only OS, Ubuntu GNOME 15.04 (64-bit), does not support UEFI boot, and only Legacy. So is there anything that I can do about this so that I can enable Secure Boot? And why does it only support Legacy anyway? And just as a quick note, this didn’t work when I had Windows 7 (a long long time ago in a galaxy far far away. ) either.

You may be able to convert the bootloader to use UEFI (see here) but it may be easier to do on a fresh install. You will probably need a x86_64 install though.

@Wilf: Sorry, I am not familiar with all this, how do I do a x86_64 install? Could you perhaps post all this as an answer (including the fresh install bit and the converting of the bootloader if I prefer to do that). 🙂

LInus does not think secure boot is required: zdnet.com/… But in future in may be. All current versions of Ubuntu will install with secure boot. Better to use newest as many updates. Also make sure your UEFI/CSM is most current from vendor as they also are making many fixes. You often have to explicitly change settings to allow boot from USB or DVD as secure boot normally does not allow other devices. help.ubuntu.com/community/UEFI

2 Answers 2

Boot loaders are written for the computer’s firmware. This is analogous to software, which is written for a particular OS. Thus, you don’t «convert. the bootloader to UEFI»; that would be like «converting the mail client to Windows» or «converting the photo editor to Linux.» Instead, you install a new program for the desired environment. In some cases, the new program may have the same name as the old one (as in Thunderbird or GIMP, which are available for both Windows and Linux; or GRUB 2, which is available for both BIOS and EFI). In other cases, there are OS- or firmware-specific programs, such as efibootmgr (a Linux-specific tool) or rEFInd (an EFI-specific boot manager).

If your computer is currently booting in BIOS/CSM/legacy mode, then to boot in EFI mode, you must do several things:

• Convert the disk from the Master Boot Record (MBR) to the GUID Partition Table (GPT). This step may not be strictly required, but some EFIs can be fussy, and using MBR may require installing your boot loader to the fallback filename ( EFI/BOOT/bootx64.efi ), which most tools won’t do by default. Thus, an MBR-to-GPT conversion is desirable. This can be done fairly painlessly with my gdisk program (which is installed in Ubuntu by default), as described here.
• Create an EFI System Partition (ESP). This is a partition where EFI boot loaders reside. It has no exact equivalent in BIOS. You’ll probably have to use GParted to resize at least one partition to make room for the ESP. I recommend making it 550MiB in size. Although an ESP is usually the first or second partition on a disk, the realities of partition resizing mean that it may work better to make it the last partition on the disk if you’re converting from BIOS/MBR to EFI/GPT.
• Install an EFI boot loader. GRUB 2 is the traditional boot loader, and it can be installed fairly automatically by booting an Ubuntu live CD in EFI mode and running Boot Repair. Boot Repair should also set things up to work with Secure Boot. Most other boot loaders will require jumping through some extra hoops to work with Secure Boot, although sometimes this isn’t too bad — if it detects Shim (the most common Linux tool for supporting Secure Boot), my own rEFInd will set itself up to use Secure Boot.
• Reboot and hope it all works. Any number of things can go wrong with all this. If you have problems, your best bet is to search here and elsewhere for a solution, and if you don’t find one, post a new question here or on some other forum.

Note that in a Linux installation, the only truly critical software difference between a BIOS-mode and an EFI-mode installation is the boot loader. Thus, switching from BIOS-mode to EFI-mode booting doesn’t require additional software changes. (In practice, installing an EFI-mode GRUB is likely to pull in some other related packages, like efibootmgr . These are indeed helpful, but not critical for booting.) There are no changes to the kernel, C libraries, shells, GUI, or other core tools required under EFI compared to BIOS. As I’ve written above, partitioning will need to be adjusted, but that doesn’t require any software changes. Secure Boot requires Shim, PreLoader, or special custom setups; and depending on the boot loader, a signed kernel may be required.

As you might gather from this, Ubuntu should work fine with Secure Boot. (There are occasional exceptions because of finicky EFIs, though. Also, using Secure Boot makes it easier to misconfigure something so that it breaks.) When doing a fresh install with Secure Boot active, it should all be pretty transparent. When you do a conversion from an existing BIOS-mode installation, you’re more likely to run into problems, since conversion tools don’t really exist (unless you count Boot Repair, which does only part of the job). Thus, you’ll end up doing more manually, which means there’s more room to miss a step or make a mistake.

For more information on Linux and Secure Boot, read my main Web page on the subject, which covers basic principles and typical configurations. If you want to go really hard-core with a custom Secure Boot configuration, read my page on taking complete control of Secure Boot. This describes how to configure the system to boot with Secure Boot active but without Shim or PreLoader, and in a way that enables you to lock Microsoft tools out, if you so desire.

Источник