My goal is that after I re-install grub, everything will keep working as itâs working now.
By âboot holeâ I mean the security hole in grub that got fixed lately with the stable update from 2020-08-16. In the review of the update @philm says :
So I want to re-install grub as @philm said. My system is BIOS-MBR but itâs also fully encrypted.
Iâm sorry for not being clear enough. I donât want to destroy ubuntu bootloader. I simply want to re-install grub like @philm said in his latest update. But I fear that re-installing grub will change something in my setup and I wouldnât be able do boot manjaro because of the fully encrypted partitions that I have.
I donât know where, currently, the âgrub screen that asks for passwordâ (before the grub menu) is residing in my setup, and I fear I would mess it up when I re-install grub.
I guess that the âgrub screen that asks for passwordâ is placed somewhere (maybe on sda and not sda1?) and itâs un-encrypted. But Iâm not sure how such a thing works with BIOS and LUKS encrypted root partition.
Are you asking if Iâve tried this when I first installed manjaro?
No. Back then I used the gui installation wizard and I approved the setup that was offered which was full disk encryption with LUKS. I didnât allocate a special partition for boot and it seems that the wizard itself didnât allocate one.
If youâre asking if Iâve tried this now. Then no, I havenât. I understand that these instructions for the preparations of the boot partition, need to executed before the system is installed.
Are you suggesting that I shrink the encrypted partition of sda1, create a new un-encrypted partition (say sda3) and then try to make this the boot partition?
Iâm aiming for Primum non nocere. Shrinking an encrypted partition and changing boot to another partition seems like something that if I try will probably make more harm then good. I guess someone more knowledgeable can do it easily, but not me.
Thanks @stephane. This answers questions #1 - I should update grub before reboot.
Unfortunately, the issue that @Florian had there refers to him not typing his password correctly. I canât understand if his setup uses BIOS (like me) or UEFI.
Do you think we can assume that if his error was only related to not typing his password correctly that the grub re-installation is not going to mess the initial screen where one enters his passpharse to decrypt the root partition? (or we still need to understand if he uses BIOS or UEFI?)
There are some disks that contain only media files so Iâm not copying their info here in order to keep this post short (sda is where manjaro is, sde is where ubuntu is):
$ sudo parted -l
Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sda: 240GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 222GB 222GB primary
2 222GB 240GB 18.5GB primary
Model: ATA KINGSTON SUV5001 (scsi)
Disk /dev/sde: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 103GB 103GB primary ext4 boot
2 103GB 120GB 17.5GB extended
5 103GB 120GB 17.5GB logical linux-swap(v1)
$ sudo efibootmgr -v
EFI variables are not supported on this system.
$ test -d /sys/firmware/efi && echo efi || echo bios
bios
I noticed the inxi -Mxxxza printed âUEFI [Legacy]â. So it seems that my motherboard is willing to work with UEFI (and/or BIOS?) but that my manjaro install is installed with BIOS? Is that an issue for the grub re-installation?
Do I need to do anything special to deal with grub re-installation if my whole partition is encrypted?
Where does the grub screen that ask for passphrase (before the grub menu) reside?
If it boots at start, it means itâs not encrypted. (could something reside on /sda and without being on /sda1 and not even on /sda2?)
Does the grub re-installation also affect this grub-passphrase-screen?
Now that I inquire deeper, and look at the flags that parted -l prints, I also see a boot flag on another drive which stores media files.
Model: ATA Hitachi HTS54101 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 946GB 946GB primary ntfs boot
2 946GB 1000GB 54.5GB extended
5 946GB 1000GB 54.5GB logical
Could this be a relic of an old OS that was once on this disk before I attached it to my current PC?
How can I know which partition (sde1 of ubuntu or sdc1 that stores only media files) is responsible for the grub passphrase screen?
Thanks @Florian! I wanted to ask you this after I read your post but I didnât get to it.
It does help because now I know I have a different situation and must understand how BIOS + full disk encryption works on my setup.
I did some checking. I disconnected sdc and sde and tested few things. Then reconnected them and tested again.
It seems that whenever sda is the first boot priority (on my motherboard), then I get to grub passphrase screen. If sdc and sde are disconnected, I can still get to the grub passphrase screen. So (I guess) I can assume that whatever triggers the grub passphrase screen is located somewhere on sda.
Iâm still left with the question, how is re-installing grub (to sda? sdc? sde?) is going to affect my systemâs decryption/passphrase screen.
Please note my comment here. This might not be as big of a vulnerability as it first appears.
If you still want to fix the vulnerability, youâve got a bit of a complex setup that not a lot of users are likely to have experience with.
To be sure about how something will work on your system without changing it, Iâd recommend creating a VM and testing the changes there:
Install virtualbox
Replicate your existing install (partitions/disks/OSâs) in a new VM
Snapshot the VM
Attempt to re-install grub
If you bork the VM, you can revert to a snapshot, while gaining knowledge of what not to do without impacting your actual system.
If you encounter specific errors, you can report back here and we can try to assist with those.
Notes:
With your system being encrypted, it is especially important to have a backup of your data in the event that it becomes inaccessible. That way if things go awry, at the very least youâll be able to re-setup your system without losing that.
Fixing this vulnerability is not something that needs to be rushed. You can continue to update your system to future updates without re-installing grub and your system should continue to function like normal. You can take all the time you need to research/prepare for re-installing grub until youâre confident you can do so without losing data
Thank you for your idea and for confirming that itâs OK to update the other packages without re-installing grub!
I tried your idea of creating a VM:
I copied and converted my sda disk (the one with the root partition and the swap partition) to a qcow2 file and tried loading it in virt-manager.
I get to the passphrase entry screen where Iâm being asked to enter my passphrase:
SeaBIOS (version ?-20200516_175120-fekuxinnars2)
Machine UUID ea196e19-ABCD-ABCD-ABCD-ABCDEFGHIJKL
iPXE (http://ipxe.org) 01:00.0 CA00 PCI2.10 PnP PMM+12345678+12345678 CA00
Booting from Hard Disk...
GRUB loading..
Welcome to GRUB!
Atempting to decrypt master key...
Enter passphrase for hd0.msdos1 (bZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ):
(bZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ is the root partition on sda1)
(Normaly I wouldnât get the first 3 line that begin with âSeaBIOSâ âMachine UUIDâ and âiPXEâ. I guess itâs related to virt-managerâs BIOS setup. In my un-virtualized setup I see the motherboardâs BIOS screen that then disappears and then I get to the âBooting from Hard Disk⌠GRUB loading⌠Welcome to GRUB!..â screen.)
When I enter my passphrase I then get to the grub menu where I can choose between manjaro and ubuntu (I canât really choose ubuntu because I only cloned sda and not sde and the other disks). After few seconds I get an error message saying:
mount/openswap_keymount: no filesystem type specified
Device /dev/disk/by-uuid/bYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY does not exist or access denied.
unmount: can't unmount openswap_keymount: Invalid argument
Error: resume: hibernation device '/dev/mapper/luks-bZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ' not found
Error: device '/dev/mapper/luks-bZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ' not found.
Skipping fsck
mount: /new_root: no filesystem type specified.
You are now being dropped into an embergency shell
sh: can't access tty; job control turned off
[rootfs ]#
bYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY is the swap partition (sda2)
bZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ is the root partition (sda1)
By the way, I canât type anything after â[rootfs ]#â. I thought Iâll be able to get more info.
I can miss-type my passphrase at the beginning and then get to a grub_rescue command line, but I donât know if that helps.
Does this mean itâs impossible to clone a LUKS-encrypted disk and run it in a virtual machine for testing?
In an effort to better understand my system, I recently grabbed an old Thinkpad and installed Arch using luks encrypted lvm2 containers. The process is quite similar between uefi and bios and youâll probably have a better idea about the ideas involved in your re-installation of grub and your system in general. Just a thoughtâŚ
sudo su
cryptsetup luksOpen /dev/sdaX crypto ( here volume mapper encrypted )
cryptsetup luksOpen /dev/sdaY swap ( case out encrypted )
mount /dev/mapper/crypto /mnt
mount /dev/sda1 /mnt/boot/efi ( if you need Efi )
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -t devpts pts /mnt/dev/pts/
chroot /mnt
I have taken a backup with clonezilla (though Iâm not sure it will be able to restore encrypted partitions and MBR without extra problems). I have backups of my data. But I donât currently have the time to mess with re-installation of the OS or to try and solve future errors that might arise with clonezilla.
So since
Iâm going to leave this for later.
I did update my machine with latest updates (without re-installing grub) and everything is fine.
I donât know if I should mark this as the solution to my original question (since it doesnât solve the question itself), but this ends my inquiry regarding that issue for the time being.