Mint 17.X to 21.X and LMDE 6 Full Disk Encryption (directory /boot included) - Using LUKS2, SecureBoot & TPM 2.0+PIN

[dobp]

Linux22, would you be able to give me some clues on how to sign additional drivers to make them work with Secure Boot once all the initial setup has already be done (following Method 1 of the Appendix A of your tutorial)?
In particular, on the machine described in the previous post should be added Virtualbox 6.0, which needs to have its driver signed to in order work with SecureBoot enabled.
A solution is proposed at https://stegard.net/2016/10/virtualbox- ... untu-fail/, but it does not work out of the box on the given machine. Maybe with the tools you recommend using in your tutorial?

[linux22]

Hello dobp, I have read your message. I think that if you have installed your system following Method 1 of the Appendix A of my tutorial https://community.linuxmint.com/tutorial/view/2496 you can try and sign your VirtualBox kernel modules with your own custom keys,
but you must remember two things:

1) it seems that linux kernel modules must be signed with "kmodsign" tool

2) "kmodsign" need certificates in DER format

For more detail see https://wiki.ubuntu.com/UEFI/SecureBoot/Signing

Update:
Other sources says that kernel modules can be signed with the "scripts/sign-file" script.
For more details see first https://www.kernel.org/doc/html/v4.15/a ... gning.html


I never did this before, because I simply disable Secure Boot when I need to use VirtualBox.


Please keep me informed about your progress.

Regards.

linux22

[dobp]

Hello linux22

I did not thank you for your feedback so let me do it now!
On the same occasion, I wanted to share my progress on this topic (which is not satisfying yet) and ask you another question (cf. below in bold).

This source indicates that VirtualBox 6.0.10+ does not require to sign anything manually anymore with Ubuntu/Debian.
Other users, posting on Virtual box's website claim they manage to make it work (on Debian 10 with VB 6.0.10 but a similar method is also used on Ubuntu there). In my case (LM 19.3 Cin 64bits) I can't make it work - more precisely I can't manage to enroll the MOK key and get blocked at step 6 (of VB ticket's comment 30) with the following message vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why. and nothing related to it in the dmesg output.
VirtualBox automated way (via /usr/lib/virtualbox/vboxdrv.sh) uses kmodsign whereas the manual method uses the sign-file tool.

Now, I fell on the two following topics by the same author (who uses a dual boot install Linux Mint/Windows 7 and unfortunately got his topic closed as off-topic in AskUbuntu due to its link to Linux Mint):
https://askubuntu.com/questions/1190742 ... th-mokutil
https://askubuntu.com/questions/1170805 ... el-modules
On the basis of these last pieces of information, I wonder two things:

• Am I blocked due to hardware incompatibilities? I am indeed trying to get VirtualBox working with SecureBoot on a Asus laptop (with Asus motherboard).

• Or has it to do with a Grub issue ? Indeed, a comment in the second link recommends running grub-install --uefi-secure-boot and to "disable CSR in the firmware". I don't see what "disabling CSR" refers to, but I ran the command and when I reboot I now get a secure boot violation error displayed (cf. below screenshot). When clicking OK, it resumes to LUKS prompt for master password and normal behavior, but it does help to enroll the MOK key. ==> Do you think I should repeat the Method 1 of the Appendix A of your tutorial to get it work? Also is there a reason why you did not include --uefi-secure-boot flag to grub-install in your tutorial?

[linux22]

I think it would be better to find a better solution, i.e. signing the VB modules with our own UEFI custom keys (i.e. these of tutorial 2360).

So I am on the run for testing 3 different methods for getting VB working with Secure Boot enabled:


1) trying to sign the VB modules with "kmodsign"

2) trying to sign the VB modules with the "scripts/sign-file" script

3) trying to add the VB modules to the linux kernel image and then signing it


At the moment I do not have a spare PC UEFI for testing these methods, so I think I will not be ready before the end of April 2020.

See you as soon as possible and in any case by the end of April 2020.


Regards.

linux22

[linux22]

Hello dobp, I have done a small step forward to solve the problem. I do not know how VB load its kernel modules but if it uses modprobe that can be a problem.

I have signed the VB kernel modules with the "scripts/sign-file" script and loaded them with insmod before running VB.

In this way VB run also with Secure Boot enabled.

But every time you reboot your PC you must reload the VB kernel modules manually with insmod and then run VB.

Anyway please try this method and tell me if it works for you.

The terminal commands to commit are:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxdrv.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetflt.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetadp.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxpci.ko

sudo insmod /lib/modules/$(uname -r)/misc/vboxdrv.ko
sudo insmod /lib/modules/$(uname -r)/misc/vboxnetflt.ko
sudo insmod /lib/modules/$(uname -r)/misc/vboxnetadp.ko
sudo insmod /lib/modules/$(uname -r)/misc/vboxpci.ko

The first quartet signs the VB kernel modules.

The second quartet loads the VB kernel modules and must be committed every time that you reboot your PC.

Then you can run VB with Secure Boot enabled.

I am still working for a better solution.

See you later.


Regards.

linux22

[linux22]

Hi dobp, I think I have solved the problem.

VB set an udev rule in file "/etc/udev/rules.d/60-vboxdrv.rules". Here VB tell to the kernel to load its kernel modules required at boot-up.

The contents of /etc/udev/rules.d/60-vboxdrv.rules should be something like that:

---
KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="vboxusers", MODE="0660"
KERNEL=="vboxdrvu", NAME="vboxdrvu", OWNER="root", GROUP="root", MODE="0666"
KERNEL=="vboxnetctl", NAME="vboxnetctl", OWNER="root", GROUP="vboxusers", MODE="0660"
SUBSYSTEM=="usb_device", ACTION=="add", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}"
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}"
SUBSYSTEM=="usb_device", ACTION=="remove", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor"
SUBSYSTEM=="usb", ACTION=="remove", ENV{DEVTYPE}=="usb_device", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor"
---

If your PC has Secure Boot enabled and your modules are not signed they are simply NOT LOADED at boot-up !

So if you have installed Linux Mint and enabled Secure Boot following my tutorial https://community.linuxmint.com/tutorial/view/2496 you must sign your VB kernel modules committing the following terminal commands:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxdrv.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetflt.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetadp.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxpci.ko

Then DO NOT TRY to start VB but simply reboot your PC and udev will load your signed VB kernel modules at every boot-up.

Remember that you must re-sign your VB kernel modules every time that they are changed (i.e. VB package update, ecc.).

I have tested this solution on my QEMU/KVM virtual machine and on my real PC Intel NUC6I5SYH and it seems working smoothly.

Please try this method and tell me if it works also for you.


Regards.

linux22

[dobp]

Hi Linux22,

Thank you very much for your prompt reply, above my expectation with this solution proposal!
I am now trying to solve my "secure boot violation" error and will then apply your solution and give you a feedback.

Best,
dobp

[dobp]

Hi Linux22,

It worked perfectly, congratulations and thanks again and for solving this case, what is more in a much easier way that I could imagine.

Let me share herebelow several points I've gone through:

1. Detailed feedback on my experience of signing Virtualbox kernel modules with your method on an Asus 2019 Laptop

- As mentioned previously I had already followed your tutorial #2360 (Appendix 1 - Method A) and then had already everything settled in /boot directory as required.
- It worked exactly as your described to sign kernel modules for VirtualBox 6.0
- I updated to VirtualBox 6.1.4, and with this version there is no vboxpci.ko file in the [...]/misc/ folder. Therefore, simply running the following was enough to make it work:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxdrv.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetflt.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetadp.ko

Do not open VB
Reboot
Launch VB

-----------------------------------------------------------------------------------

2. Is there a "vulnerability" in our encryption strategy (quite light anyway if so, as only related to an expected effect of boot directory encryption)?

The "Secure Boot violation error" I caused by running grub-install --uefi-secure-boot was eventually easy to fix. I've come to assume it was due to that command which updated the file grubx64.efi, so I remembered the warning you give in your tutorial #2360 saying that everytime grub will be updated, it will be necessary to sign again the files. Although all the Linux Mint updates of the last 6 months (including kernel or grub updates which perform update-grub command) has never required me to sign the EFI file again so far, I followed below steps as indicated in your tutorial (based on Appendix A - Method 1) and it was enough to remove the Secure Boot error.

sudo -i
cd /boot/efikeys

update-grub
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Mint --boot-directory=/boot --modules="all_video boot btrfs cat chain configfile crypto cryptodisk disk diskfilter echo efifwsetup efinet ext2 fat font gettext gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool gfxmenu gfxterm gfxterm_background gzio halt hfsplus iso9660 jpeg keystatus loadenv loopback linux linuxefi lsefi lsefimmap lsefisystab lssal luks lvm mdraid09 mdraid1x memdisk minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png raid5rec raid6rec reboot search search_fs_uuid search_fs_file search_label sleep squash4 test true verify video zfs zfscrypt zfsinfo" --recheck

cp -b -f /boot/efi/EFI/Mint/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi

sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Mint/grubx64.efi /boot/efi/EFI/Mint/grubx64.efi
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/BOOT/bootx64.efi /boot/efi/EFI/BOOT/bootx64.efi

sync

sbverify --cert db.crt /boot/efi/EFI/Mint/grubx64.efi
sbverify --cert db.crt /boot/efi/EFI/BOOT/bootx64.efi

exit

However, it makes me wonder whether this could be the way of a possible attack to our encryption strategy.

Usually, with the dual boot FDE (directory /boot included) I set up adapting other great tutorials of yours), directly after pressing the Power button comes a LUKS screen asking for Master Password. Then it boots on GRUB which offers the choice of booting to Linux Mint (bootx64.efi), Linux Mint again (named Ubuntu for some reasons - grubx64.efi), Windows Bootloader, or System setup (Asus UEFI Setup).

With the error coming up, after pressing Power button, it first displayed the error screen (red screenshot attached to my penultimate post), and it was necessary to press ENTER so that the LUKS screen would appear (and then as usual, except that the boot option "Ubuntu" - grubx64.efi was leading to displaying the error again, since it was the file which was tampered with and which Secure Boot therefore prevented the execution).
But if you were pressing ESCAPE instead of ENTER at the error screen, then it was displaying the boot order menu (related to Asus UEFI, so I guess ESCAPE would be the "F something" key with other brand), which was then allowing to somehow bypass the boot partition encryption. More precisely, it displayed the boot options, so:

• if you clicked on Linux Mint, then it would display LUKS screen, then usual GRUB menu once master password was entered;
• if you clicked on Windows Bootloader, it was booting to it directly (no LUKS screen);
• if you clicked on System Setup it booted on Asus UEFI Setup.

In normal circumstances (without the error screen), pressing ESCAPE (i.e. at LUKS screen) displays GRUB CLI recovery Menu.

Asus UEFI Setup allows to define two different kind of passwords: an Administrator Password which protects the access to the Asus UEFI Setup utility, and a User Password that is asked everytime at boot time (after pressing the power button). As per the recommendation you provide in the tutorial #2360, I had set up an Asus UEFI Admin Password to protect the ability of turning Secure Boot off. However I did not set up a User Password as I thought one password at boot (the one to be entered at LUKS screen) would be enough.
I nevertheless tried all cases when having the error:

• With Admin Password only, it displays the error. if you press ESCAPE, then it asks for Admin Password. if you have the good password it brings you to the UEFI boot menu (i.e. bypass of boot encryption via LUKS). If you have wrong password, it still brings you to the same boot menu, except that if you choose System Setup item, then you have access to a limited version of the utility (e.g. you cannot turn off Secure Boot).
• With User Password only, Asus UEFI utility asks immediately for a password after pressing the Power button. If you had pressed ESCAPE key, if you have the good password it brings you to the boot menu (i.e. bypass of LUKS screen). If the password is wrong you are blocked there.
• With Admin + Password, a User Password prompt appears at boot, but if you enter Admin Password it works as well (grants you all priviledges to change System Setup if you had pressed ESCAPE key and select System Setup in UEFI boot menu).

To summarise, I am under the impression that with the current Dual Boot FDE install (/boot included) [there might be the same issue with a "simple boot" install, except that it would therefore not offer the Windows Bootloader option], tampering with an EFI file in order to provoke a Secure-Boot violation would allow bypassing the effect of boot directory encryption in granting access to the boot menu via UEFI utility interface. For now, the only means I see to address this issue is adding a UEFI User Password to prevent this behaviour. It is not very convenient as it adds up to boot time (2 passwords...).

-----------------------------------------------------------------------------------

3. Two theoretical questions (not essential - I do not want to abuse of your time...)

Following your tutorial about custom keys and trying to figure out how to solve the issue discussed hereinabove helped me to better understand the logic of secure boot, even though I am still far from mastering it.
I write here a few "theoretical" questions in case you would be able to consider them:

• Is there a reason why your tutorial #2360 does not include the flag --uefi-secure-boot for grub-install as indicated here for example ? In practice I do not mind as I did not encounter any particular issue due to this so far.
• What is the difference between sbsign and sign-file tools? Do you think it would have been possible to sign Grub EFI files with sign-file or VirtualBox kernel modules with sbsign ?

Hmmm sorry for such a long post and thanks again.
Best,
dopb

[linux22]

Hello dobp, I have read your message. About your last questions my opinion is:

1) I think I must explain something about LINUX KERNEL, GRUB and other Ubuntu/Mint packages marked as "Signed".
These packages have files that are signed by the distro manufacturer company, but ONLY for Windows system.
So if you have installed your own UEFI custom keys inside your PC all the Signed packages are useless and do not
work for you. This is also true for the grub-install --uefi-secure-boot option, which try to install the GRUB files from the
GRUB "Signed" package. All the distro packages marked as "Signed" are usable only inside a PC UEFI with Secure
Boot enabled and the default keys supplied by Microsoft (except PK key). These packages are useful when you try to
install Linux inside a standard PC with Secure Boot enabled (normally equipped with UEFI Secure Boot keys supplied
by Microsoft). I think it is better to configure our PC with our own custom UEFI Secure Boot keys, but if you need a
dual boot installation (W10+LM) it is mandatory to install your own custom keys alongside those of Microsoft.

2) It is possible to disable the GRUB recovery menu but if an attacker want to unlock your LUKS volume he NEED your
password. Without your password it can not access your LUKS volume, unless it tamper your grubx64.efi file. But if
your grubx64.efi file is signed and Secure Boot is enabled the tampered .efi file CANNOT boot, ANYWAY. I am much
more worried about hardware keylogger, BIOS/UEFI firmware reflash and network intrusions while our PC are online.

3) For grub-install --uefi-secure-boot option see item 1). For the differences between sbsign and sign-file I can say that
the first one is intended for signing bootable .efi files while the second one is intended for signing the kernel modules.
Anyway I can say that the linux tools for the configuration of UEFI related parameters and especially those for Secure
Boot seem still rudimental and they change quite often. Today another great limitation is the lack of documentation or
its incompleteness.

Regards.

linux22

[dobp]

Thank you for your explanations linux22, it is much clearer for me now.

Regarding 2), for clarity's sake (or maybe it is the same?), what I reported was not the fallback to Grub Recovery Menu when pressing ESC, but the fact that when having the error, Grub/LUKS password prompt could be bypassed to display directly the boot options (via Asus UEFI utility, not GRUB). But anyway, it is not a big issue since as you said it does not impact disk encryption (it simply allow the "attacker" to list the boot options, and this is true only when there is a secure boot violation error, which can be solved easily by generating a new grub EFI file and signing it - cf. your tutorial or my previous post).

Best,
dopb

[dobp]

Dear Linux22,

As explained previously here, I have a machine for which I followed your instructions to get a FDE dual boot system, with Secure Boot enabled (using the original Microsoft UEFI Secure Boot certificates of my PC UEFI platform - Method 1).

Currently under Linux Mint 19.3 64bits Cinnamon, I authorised yesterday mintupdate to perform the update from grub 2.02-2ubuntu8.15 to grub 2.02-2ubuntu8.16.
When rebooting, I got that red rectangle warning for a secure boot violation (which warns but does not prevent the system to function correctly).
I had taken notes from your tutorial and previous experience of the same issue of the following commands, which I ran in order to sign the new Grub EFI files that were - I presume - causing the issue:

Code: Select all

sudo -i
cd /boot/efikeys

update-grub
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Mint --boot-directory=/boot --modules="all_video boot btrfs cat chain configfile crypto cryptodisk disk diskfilter echo efifwsetup efinet ext2 fat font gettext gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool gfxmenu gfxterm gfxterm_background gzio halt hfsplus iso9660 jpeg keystatus loadenv loopback linux linuxefi lsefi lsefimmap lsefisystab lssal luks lvm mdraid09 mdraid1x memdisk minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png raid5rec raid6rec reboot search search_fs_uuid search_fs_file search_label sleep squash4 test true verify video zfs zfscrypt zfsinfo" --recheck

cp -b -f /boot/efi/EFI/Mint/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi

sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Mint/grubx64.efi /boot/efi/EFI/Mint/grubx64.efi
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/BOOT/bootx64.efi /boot/efi/EFI/BOOT/bootx64.efi

sync

sbverify --cert db.crt /boot/efi/EFI/Mint/grubx64.efi
sbverify --cert db.crt /boot/efi/EFI/BOOT/bootx64.efi

exit

Then after reboot, the Secure boot violation warning screen disappeared BUT I ran into more annoying issues which I am not too sure on how to deal with so far. After entering LUKS password comes the Grub screen asking whether I want to boot on Linux Mint / Windows / BIOS parameters:
1. If I choose for Linux, it does not boot and comes instead the following error message:

Code: Select all

Error: /boot/vmlinuz-5.4.0-42-generic has invalid signature.
Error: You need to load the kernel first
Press any key to continue

When pressing a key it brings back to Grub menu. I tried to revert to earlier kernel versions for test purposes, but I am getting equivalent error messages.
2. If i choose Windows Bootloader, it works as expected.
3. If i choose BIOS parameters - not sure whether this is related but I never noticed it before - nothing weird until i exit the parameters and that it brings back to LUKS password screen displaying the error Error: failure reading sector 0x0 from 'hd0'., followed by the usual Attempting to decrypt master key... [etc.]. If I enter correct password, then it leads to Grub menu, but if I enter incorrect password it outputs some error messages I never saw before (basically failure of reading various sectors of 'hd0' and also 'no such cryptodisk found')

If I disable Secureboot I can access Linux again.
It seems I have to sign all kernel files, but I am currently wondering why (never had to do it so far) and how!
Did you ever faced this case or have some insights about it ?
Here is for info the content of /boot:

Code: Select all

config-4.15.0-106-generic
config-4.15.0-108-generic
config-4.15.0-109-generic
config-4.15.0-111-generic
config-4.15.0-112-generic
config-4.15.0-54-generic
config-5.0.0-32-generic
config-5.3.0-53-generic
config-5.3.0-59-generic
config-5.3.0-61-generic
config-5.3.0-62-generic
config-5.4.0-42-generic
[DIR] efi
[DIR] efikeys
[DIR] grub
initrd.img-4.15.0-106-generic
initrd.img-4.15.0-108-generic
initrd.img-4.15.0-109-generic
initrd.img-4.15.0-111-generic
initrd.img-4.15.0-112-generic
initrd.img-4.15.0-54-generic
initrd.img-5.0.0-32-generic
initrd.img-5.3.0-53-generic
initrd.img-5.3.0-59-generic
initrd.img-5.3.0-61-generic
initrd.img-5.3.0-62-generic
initrd.img-5.4.0-42-generic
memtest86+.bin
memtest86+.elf
memtest86+_multiboot.bin
System.map-4.15.0-106-generic
System.map-4.15.0-108-generic
System.map-4.15.0-109-generic
System.map-4.15.0-111-generic
System.map-4.15.0-112-generic
System.map-4.15.0-54-generic
System.map-5.0.0-32-generic
System.map-5.3.0-53-generic
System.map-5.3.0-59-generic
System.map-5.3.0-61-generic
System.map-5.3.0-62-generic
System.map-5.4.0-42-generic
vmlinuz-4.15.0-106-generic
vmlinuz-4.15.0-108-generic
vmlinuz-4.15.0-109-generic
vmlinuz-4.15.0-111-generic
vmlinuz-4.15.0-112-generic
vmlinuz-4.15.0-54-generic
vmlinuz-5.0.0-32-generic
vmlinuz-5.3.0-53-generic
vmlinuz-5.3.0-59-generic
vmlinuz-5.3.0-61-generic
vmlinuz-5.3.0-62-generic
vmlinuz-5.4.0-42-generic

EDIT: I see that in some tutorials you've now switched to EFI Stub boot, among other thing to avoid these kind of troubles, but I suppose it is not applicable for dual boot ?

[cozyknight]

Hello,

I've been utilizing your guides for several years now so thank you for putting those together. I often end up reinstalling my operating system for one reason or another and decided to try and automate your latest guide.

Below I linked to pastebin of the script I made using your guide. I took instructions from the pdf and just copied them into the script and added variables where they were needed. This particular script uses the instructions for Mint 20 installed on ext4, I do eventually plan to add some basic conditional statements to allow switching between the different versions you had in the guide.

One thing I noticed was while putting this together, was that the pdf added newline characters in the middle of some of the longer commands. I think I caught them all, but a second set of eyes wouldn't hurt.

Pastebin - Mint 20 FDE script
Pastebin - objcopy_update_hook

How to use this script:
When you boot the live CD/USB to install the OS, save these two files to the home directory. (either put them on a USB drive and transfer them or download them from pastebin while on the live CD/USB.

Mark the script executable either through the properties menu or the terminal

Code: Select all

chmod +x mint-20-fde.sh

Change any of the variables at the top of the script as needed to match your installation requirements.

Then run the script.

Code: Select all

./mint-20-fde.sh

And just follow the prompts. This script follows the guide step for step, and I tried to comment it as clearly as I could; let me know if I can make it clearer.
The second file contains the hook described in step 42, that you need to copy to the file that is made during the installation process. Note: If someone knows how I can automate that, I would appreciate the input.

I've tested this script 3 times in virtual machines, additionally I used it on my laptop and had no errors. But again this version of the script is for Mint 20 only utilizing Linux22's guide.

I hope this helps. Please let me know if you have suggestions or if I need to change something.

Edit: After glancing over a few of the posts in this thread I felt I should add a disclaimer that, this is based on the mint 20 ext4 w/o hibernation guide. I don't get a lot of time to work on this sort of stuff, but I eventually want to be able to add support for the secure boot (which currently I am out of my element with, so help there is appreciated.) along with the other variations of this guide mentioned above.

[stussy1]

Hi all-

I have a (hopefully simple) question regarding the FDE process outlined in the "Linux Mint 19.X and 20.X with Full Disk Encryption, directory /boot included
PC with firmware UEFI & HDD with GPT partitioning scheme - Booting with EFI STUB loader" document. First, thanks Linux22 for your work on these documents, I've previously used your guide for FDE on my older Linux Mint system from several years ago.

My question is this: with the FDE now available in the Linux Mint installer, what is the difference (advantages/disadvantages) of using the installer's FDE setup instead of going through this process of manually allocating LUKS partitions and setup?

Thank you.

[cozyknight]

Hi all-

I have a (hopefully simple) question regarding the FDE process outlined in the "Linux Mint 19.X and 20.X with Full Disk Encryption, directory /boot included
PC with firmware UEFI & HDD with GPT partitioning scheme - Booting with EFI STUB loader" document. First, thanks Linux22 for your work on these documents, I've previously used your guide for FDE on my older Linux Mint system from several years ago.

My question is this: with the FDE now available in the Linux Mint installer, what is the difference (advantages/disadvantages) of using the installer's FDE setup instead of going through this process of manually allocating LUKS partitions and setup?

Thank you.

To my understanding the main disadvantage of using Ubiquity's FDE option is that it does not encrypt the swap partition. Additionally, though I do not entirely understand the process and what needs to be exposed and what doesn't, Ubiquity's fde option doesn't protect the boot partition, leaving it vulnerable to various bad actors.

Two other advantages are the primary reasons I've been using Linux22's guides the past few years is that the partitions can be customized and with some determined tweaking, you can have a dual boot system, with FDE. In the past I used to dual boot Windows and I wanted my Linux partitions encrypted, and this guide is how I was able to do it.

That's just my humble understanding of the differences. I wish Ubiquity would implement this into the installer though.

[linux22]

Hello cozyknight, stussy1 and dobp. I have read your messages.

I just replaced my old tutorial "Linux Mint (but also Ubuntu) - How to enable UEFI Secure Boot with your own Custom keys on PC with UEFI & HDD with GPT" previously available at https://community.linuxmint.com/tutorial/view/2360 (because malfuncioning and not updatable anymore) with the new one at https://community.linuxmint.com/tutorial/view/2496.

So I am now ready to answer your questions as soon as possible and anyway within the end of this month.


Regards.

linux22

[linux22]

Hello dobp. I have read your message and, as you said in your EDIT note, the problems with GRUB is the most important reason because I have switched to EFI STUB. In my past tutorial concerning Linux FDE I was always dealing with GRUB with great difficulties. So when I switched to UEFI I have found an alternative to bypass GRUB and boot Linux with a simple and reliable new method, EFI STUB. You can try this new method also on PC with dual boot W10+Linux but your PC UEFI Boot Manager must be able to deal with many boot .efi file. Most PCs with UEFI firmware have a Boot Manager that can be started pressing a Fn key at start-up (typically F8, F10, F12 ecc.). Once pressed the Boot Manager Fn key at boot-up the system load a list of all bootable .efi images found in EFI boot partition. You can then select Mint or W10 and then press Enter to start the selected OS.

About the error you get after updating GRUB I do not know how to solve your problem. If you have installed Linux Mint FDE using my old tutorial (Dual Boot) I have no clue about the error you get. Anyway you can try to sign with your own Custom keys your kernel image with 'sgsign' command and all your kernel module using 'scripts/sign-file' script but I can not say if that will work correctly.

UPDATE:

You can read more about signing Linux kernel & modules for Secure Boot at the following links:

- https://wiki.debian.org/SecureBoot

- https://ubuntu.com/blog/how-to-sign-thi ... ecure-boot

- https://wiki.gentoo.org/wiki/Signed_ker ... le_support


Very interesting the first one, especially paragraph "Secure Boot limitations" !


Regards.

linux22

[questionbot]

I tried 3 times to follow these instructions for the FDE... and the thing booted eveytime fine, the secure boot worked... but on the first update, either through the GUI packet manager or apt-upgrade or apt dist-upgrade would fail.

[linux22]

Hello stussy1. I have read your message and the response from cozyknight, who explain the most important issues of the standard FDE, available from Ubiquity.

Also the main problem is:

Can we set up a PC with a security level that make our system invulnerable ?

The answer is NO !

We can only build a system with a level of security that can keep out marauders with a low/medium hardware/software skill.


Below I put a very simple graded list of possible security solutions:

Level of difficulty 1 E(asy)
Normal linux systems

Level of difficulty 2 D(ifficult)
Normal linux systems with standard FDE (like that provided from Ubiquity)

Level of difficulty 3 D+
FDE linux systems (/boot included) (like solution of my Tutorials 2026-BIOS, 2061-UEFI, Majaro and others)

Level of difficulty 4 D+++++
FDE linux systems (/boot included) (like solution of my tutorials 2061-UEFI & 2496-SECURE BOOT and others, only UEFI)

Level of difficulty 5 D++++++++++
FDE linux systems (/boot included) (like Level 4 + TPM chip)


The above solutions can be tampered with from:

Level of difficulty 1
Normal hardware and Linux knowleges
Medium/Expert Linux subjects (usually common linux users)

Level of difficulty 2
Superior hardware and Linux knowleges
Expert Linux subjects with system programming capabilities (usually also single linux gurus)

Level of difficulty 3
High hardware and Linux knowleges
Expert Linux subjects with system programming capabilities and intelligence resources (usually single linux gurus or medium/high security skill IT companies)

Level of difficulty 4
Very high hardware and Linux knowleges
Expert Linux subjects with good hardware tampering capabilities, system programming capabilities and intelligence resources (usually govenments agencies, high security skill IT companies)

Level of difficulty 5
Highest hardware and Linux knowleges
Expert Linux subjects with highest hardware tampering capabilities, system programming capabilities and intelligence resources (usually govenments agencies, high security skill IT companies, links with specific hardware manufacturers are mandatory)


In all stage is always possible a hardware attack (i.e. hardware keylogger) and a dictionary or brute force attack but the required computing power must be very great.

Here a TOP-DOWN list of possible attack vectors:

Full disk encryption (/boot included) Secure Boot enabled + TPM chip
Access only after security chips disabling and BIOS/UEFI firmware tampering and hardware tampering

Full disk encryption (/boot included) Secure Boot enabled
Access only after BIOS/UEFI firmware and/or hardware tampering or above

Full disk encryption (/boot included) BIOS or UEFI with Secure Boot disabled
Access available only after Evil Maid Attack or above

Standard system - Encrypted
Access available only after system files tampering or above

Standard system - Not encrypted
Access available to everyone without specific tools or above


Anyway, we are vulnerable when we leave our systems on and alone and when we are connected to a network or to internet.

And finally we must never forget that if our files are really interesting for the bad guys, the ugly truth is probably best depicted in this vignette:





Regards.

linux22

[linux22]

Hello questionbot, I have read your message. Can you tell me what type of FDE solutions have you installed ?

FDE from my tutorial 2061 PC UEFI + HDD GPT + GRUB ?

or

FDE from my tutorial 2438 PC UEFI + HDD GPT + EFI STUB ?


Please tell me more about your FDE installation and the errors you get.

Regards.

linux22

[questionbot]

FDE from my tutorial 2438 PC UEFI + HDD GPT + EFI STUB ?

https://community.linuxmint.com/tutorial/view/2438

I have been trying to use this one. It seems to work fine.. even boots fine.. but it is the first update once the os is booted that fails.