Decrypting boot - decrypts root - using an empty or invalid passphrase

Kajan0v3zk1 · 24 April 2024 12:41

Environment

OS: Manjaro GNOME (latest)
boot: UEFI

Expected results

Both system partitions are decrypted with the correct passphrase.

Actual results

The root partition decrypts the system regardless of the integrity of the passphrase. There are security concerns.

About problem

Manjaro with encrypted /boot and root partitions will decrypt the root partition and display the GRUB menu, regardless of the integrity of the passphrase required for decryption. /boot works as expected, but Manjaro allows an empty or random passphrase when decrypting the root partition. This problem was discovered when trying to dual boot with Linux Mint. You can also reproduce the problem with VirtulBox by partitioning the disk in half and manually installing Manjaro on one side.

Reproduce the problem

Boot under the UEFI boot environment and install using the GUI installer manual installation with the following configuration.

sdb                        8:16   0 931.5G  0 disk  
├─sdb1                 8:17   0 476.8M  0 part  # <- /boot/eif
├─sdb2                 8:18   0     2G  0 part     # <- swap
├─sdb3                 8:19   0   464G  0 part   # <- encrypt /
└─sdb4                 8:20   0   477M  0 part   # <- encrypt /boot

Boot the OS and Enter the key to decrypt the /boot partition
Enter a passphrase that is ‘not’ the decryption key for the system partition
OS startup (problem reproduction completed)

If you have any questions, please feel free to post.

Think you

Nachlese · 24 April 2024 13:04

Thank you for giving permission to post!
Instead of the output of lsblk
please give us the more detailed output of:
lsblk -f

Normally, with the encrypted setup that Calamares can produce, everything is inside one single encrypted container (… no separate, unencrypted /boot, for instance - Calamares cannot do that)

linux-aarhus · 24 April 2024 13:55

Please elaborate.

If you provided the correct decryption phrase the grub menu is loaded and the encrypted volume is made accessible

If you provide the wrong phrase - depending on your setup you may be dropped to prompt and a reboot is required or you are given 3 attempts (plymouth encryption screen).

I don’t see wjy this is a security concern or should be labelled as bug?

I think you have a genuine selfmade issue - it is entirely possible to have separate unencrypted /boot with encrypted root. We even have a guide on how to create such setup with Calamares.

The security concern with such setup is that your kernel is placed in the accessible /boot.

If you are very concerned about this - you should definately use a fully encrypted root - and a signed unified kernel image loaded directly from your efi firmware.

Then reset Secure Boot to setup mode, clear all existing keys then boot into your system and enroll your private key. As a last step - lock your firmware with a reasonable passphrase.

Only then you can claim you have done what is possible to lockdown your system.

Encryption is not a magic wand - it is only as smart as the human configuring the system.

What you desribe is a setup which is not recommended nor are you encouraged to do so.

Please see the dm-crypt/Encrypting an entire system - ArchWiki topic for more indepth information.

mithrial · 24 April 2024 14:17

Until the author clears up open questions or rephrase their setup, we can only hypothesize.

Does maybe Calamares encrypt root (or home) with the same passphrase as boot, as well as with an additional user-defined passphrase?

linux-aarhus · 24 April 2024 14:21

I the culprit is Calamares it is an upstream issue GitHub - calamares/calamares: Distribution-independent installer framework

In any case the chosen setup is not a standard setup and thus anything can happen.

Nachlese · 24 April 2024 14:23

… or one partition (encrypted or not) holds the keyfile to decrypt the rest …
he needs to clarify

Kajan0v3zk1 · 25 April 2024 09:22

I present lsblk -f

sdb                                                                                                                       
├─sdb1                                        vfat        FAT32       492A-F1F4 # <- /boot/eif                               
├─sdb2                                        swap        1           24bb60bf-e407-41cf-87a4-8c2eed7b5f60   
├─sdb3                                        crypto_LUKS 1     76fcdf94-8774-4376-b6cb-512b86fd0771 # <- /               
├─sdb4                                        crypto_LUKS 1     a4ba34aa-34d1-47d1-80d4-80fb9ac669c9   # <- /boot                   
├─sdb5                                        ext4        1.0         de93062b-04a8-4f05-974a-b20e59225ce8 #<- Linux Mint /boot 
└─sdb6                                        xfs                     3576b7bf-63af-49fa-b839-4d16db970c93  # <- Linux Mint /

The problem is that even if I enter the wrong passphrase or the correct passphrase, the GRUB menu is displayed.
In other words, if you have a passphrase of test123, it will be decrypted even if you enter test123 at the prompt, and it will be decrypted even if you press the enter key without inputting anything.

This problem is very strange. I will show you as many cases as I can, so I ask for your cooperation.

Nachlese · 25 April 2024 10:09

Your Mint installation is unencrypted - of course you will see the grub menu without having to give the password
… is what I think - not sure though
You’ll need to dissect and clear up for yourself, which partition belongs to which of your two systems - and how they are put together.
/dev/sdb1 (the efi partition) could be a problem here

sudo cryptsetup open /dev/sdb3 encrypted_root
(“encrypted_root” is just a descriptive name - choose any name you like)
you will be asked for the password to decrypt and open the device - then you can access it

What you are saying is:
it will be opened with any password or even without one.

Is that truly the case?
You know that you have multiple key-slots, that you can have more than one password set to open the device?
Setting a second or a third one will not remove the others … all the passwords will work.

sudo mount /dev/mapper/encrypted_root /mnt

let’s see what is in there:

ls -al /mnt
ls -al /mnt/boot

I’d think /boot will be empty at this point - as you apparently have a separate and also encrypted /boot partition

same procedure:

sudo cryptsetup open /dev/sdb4 encrypted_boot
sudo mount /dev/mapper/encrypted_boot /mnt/boot

as soon as you can access /dev/sda3 you can look at /etc/default/grub and /etc/fstab

cat /mnt/etc/default/grub
cat /mnt/etc/fstab
ls -al /mnt/boot

Kajan0v3zk1 · 25 April 2024 13:00

OK, I show you the contents of the directory and files you asked for.

sdb                                                                                                                       
├─sdb1                                        vfat        FAT32       492A-F1F4                                           
├─sdb2                                        swap        1           24bb60bf-e407-41cf-87a4-8c2eed7b5f60                
├─sdb3                                        crypto_LUKS 1           76fcdf94-8774-4376-b6cb-512b86fd0771                
│ └─encrypted_root                            xfs                     68710841-0c20-47fc-bbf3-4d2cb033c44f  286.6G    38% /mnt
│                                                                                                                         /mnt
├─sdb4                                        crypto_LUKS 1           a4ba34aa-34d1-47d1-80d4-80fb9ac669c9                
│ └─encrypted_boot                            ext4        1.0         9f610c19-4e57-43fb-b0af-8e1e4c22c695  260.7M    34% /mnt/boot
│                                                                                                                         /mnt/boot
├─sdb5                                        ext4        1.0         de93062b-04a8-4f05-974a-b20e59225ce8                
└─sdb6                                        xfs                     3576b7bf-63af-49fa-b839-4d16db970c93

cat /mnt/etc/default/grub

# GRUB boot loader configuration

GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=76fcdf94-8774-4376-b6cb-512b86fd0771:luks-76fcdf94-8774-4376-b6cb-512b86fd0771 root=/dev/mapper/luks-76fcdf94-8774-4376-b6cb-512b86fd0771 splash udev.log_priority=3"
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y

# Set to 'countdown' or 'menu' to change timeout behavior,
# press ESC key to display menu.
GRUB_TIMEOUT_STYLE=hidden

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'
GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/usr/share/grub/background.png"
GRUB_THEME="/usr/share/grub/themes/manjaro/theme.txt"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to make GRUB remember the last selection. This requires
# setting 'GRUB_DEFAULT=saved' above.
GRUB_SAVEDEFAULT=true

# Uncomment to disable submenus in boot menu
#GRUB_DISABLE_SUBMENU=y

# Uncomment this option to enable os-prober execution in the grub-mkconfig command
GRUB_DISABLE_OS_PROBER=false

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically. We use 'fsck' by default, which
# needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be
# removed from 'mkinitcpio.conf' to make 'systemd-fsck' work.
# See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking
#GRUB_ROOT_FS_RO=true
GRUB_ENABLE_CRYPTODISK=y

cat /mnt/etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=492A-F1F4                            /boot/efi      vfat    umask=0077 0 2
/dev/mapper/luks-a4ba34aa-34d1-47d1-80d4-80fb9ac669c9 /boot          ext4    defaults,noatime 0 2
/dev/mapper/luks-76fcdf94-8774-4376-b6cb-512b86fd0771 /              xfs     defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

ls -al /mnt/boot

total 135814
drwxr-xr-x  6 root root     1024  4月 21 14:21 .
drwxr-xr-x 16 root root      320  4月 21 10:17 ..
drwxr-xr-x  2 root root     1024  4月 21 05:25 efi
drwxr-xr-x  6 root root     1024  4月 21 13:44 grub
-rw-------  1 root root 90577533  4月 21 14:21 initramfs-6.6-x86_64-fallback.img
-rw-------  1 root root 28131057  4月 21 14:21 initramfs-6.6-x86_64.img
-rw-r--r--  1 root root  7368704  2月  2 01:16 intel-ucode.img
-rw-r--r--  1 root root       21  4月 11 03:51 linux66-x86_64.kver
drwx------  2 root root    12288  4月 21 05:25 lost+found
drwxr-xr-x  2 root root     1024  4月  6 12:02 memtest86+
-rw-r--r--  1 root root 12976640  4月 21 06:22 vmlinuz-6.6-x86_64

I found something interesting while exploring encrypted_root again.

[root@hacktheplanet mnt]# ls -aril
total 49
268435587 drwxr-xr-x 13 root root   188  4月 21 13:38 var
      138 drwxr-xr-x  9 root root   118  4月 21 12:54 usr
805306498 drwxrwxrwt  2 root root     6  4月 21 05:28 tmp
      132 drwxr-xr-x  2 root root     6  4月 21 05:25 sys
537346178 drwxr-xr-x  4 root root    29  4月  6 12:02 srv
  7259032 lrwxrwxrwx  1 root root    19  4月 21 10:17 snap -> /var/lib/snapd/snap
      136 lrwxrwxrwx  1 root root     7  1月 20 03:16 sbin -> usr/bin
805306496 drwxr-xr-x  2 root root     6  4月 21 05:25 run
      160 -rw-r--r--  1 root root  5346  4月  6 12:03 rootfs-pkgs.txt
268435586 drwxr-x---  8 root root   282  4月 21 12:20 root
537346176 drwxr-xr-x  2 root root     6  4月 21 05:25 proc
      137 drwxr-xr-x  2 root root     6  4月 21 05:27 opt
805306497 drwxr-xr-x  4 root root    36  4月 21 09:18 mnt
  1745262 -rw-r--r--  1 root root     8  4月  6 12:05 .manjaro-tools
      135 lrwxrwxrwx  1 root root     7  1月 20 03:16 lib64 -> usr/lib
      134 lrwxrwxrwx  1 root root     7  1月 20 03:16 lib -> usr/lib
537346177 drwxr-xr-x  3 root root    18  4月 21 05:27 home
268435585 drwxr-xr-x 84 root root  8192  4月 21 13:38 etc
268435584 drwxr-xr-x  2 root root     6  4月 21 05:25 dev
  1745263 -rw-r--r--  1 root root 16213  4月  6 12:05 desktopfs-pkgs.txt
  4313047 -rw-------  1 root root  2048  4月 21 05:26 crypto_keyfile.bin
        2 drwxr-xr-x  6 root root  1024  4月 21 14:21 boot
      133 lrwxrwxrwx  1 root root     7  1月 20 03:16 bin -> usr/bin
        2 drwxr-xr-x 17 root root  4096  4月 24 03:01 ..
      128 drwxr-xr-x 16 root root   320  4月 21 10:17 .

key file exists in root directory

I’m not good at English, but this situation matches your testimony. I can read it that way

Try creating a virtual machine again under the same conditions as the other day. Perhaps there was an oversight. I’m just guessing, but it’s likely that the installer implicitly creates a key file.

Nachlese · 25 April 2024 13:16

This was mostly for you - so that you know how to analyze the situation.

I really have no great desire to debug this situation for you or even with you.

Just start over.

Is it or is it not?
You did not engage with this question.

Did you need the correct password or could you open the encrypted containers without?
Of course you needed the correct one …

also, there should be a difference in
ls -al /mnt/boot

between before you open and mount /dev/sdb4 and after

It should be empty at first, because the content is only added when /dev/sdb4 is open and mounted.

I think you attempted to create a setup that is more complicated than it needs to be - and lost track and did something wrong.

Start over is my advice …

Kajan0v3zk1 · 25 April 2024 13:46

yes is it. It can be opened with the correct or non-correct password.
That’s all I can say

Nachlese · 25 April 2024 13:51

Hard to believe.
That is all I can say.

Have look here for hints on how you can assess the situation:

https://unix.stackexchange.com/questions/318382/detemine-which-luks-slot-a-passphrase-is-in

If you decide to kill a slot, be careful to have at least one left - or you’ll lose access and cannot add a new password.
(first add a second password before you remove an existing one)

here is what it looks like when I supply a wrong password first and then the correct one

ls /dev/mapper/
control

LANG=C sudo cryptsetup --verbose open /dev/sdb4 encr
No usable token is available.
Enter passphrase for /dev/sdb4:
No key available with this passphrase.
Enter passphrase for /dev/sdb4: 
Key slot 0 unlocked.
Command successful.

ls /dev/mapper/
control  encr

LANG=C sudo cryptsetup --verbose close encr
Command successful.

ls /dev/mapper/
control

Kajan0v3zk1 · 25 April 2024 15:23

Thanks, sorry about earlier. I apologize for my weakness and rudeness.
From reading the posts in this thread, I wonder if this is a Calamares problem and not a Manjaro problem?
Until I know that I will not know enough answers or be able to dissect and discern the nature of this problem.

For now, I will reset the passphrase using the method you suggested. I’ll also dig into the luks key slot and Calamares key file based on the hint you gave.

postscript

I’m beginning to understand it, sort of.

Extract the key file I just found from the system partition in SSD:

cryptsetup open /dev/sdb3 crypt_root
mount /dev/mapper/crypt_root /mnt
cd /mnt/ && cp -v /mnt/crypto_keyfile.bin /testing-key-file.bin

Check the key slot on the LUKS device

cryptsetup luksDump /dev/sdb3 
LUKS header information for /dev/sdb3

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	512
MK digest:     	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
MK salt:       	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
               	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
MK iterations: 	109959
UUID:          	76fcdf94-8774-4376-b6cb-512b86fd0771

Key Slot 0: ENABLED
	Iterations:         	1762312
	Salt:               	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
	                      	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	1593580
	Salt:               	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
	                      	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
	Key material offset:	512
	AF stripes:            	4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Enter passphrase in Key Slot 0, check succeeds:

cryptsetup luksOpen --test-passphrase --key-slot 0 /dev/sdb3 && echo correct
Enter passphrase for /dev/sdb3: 
correct

I try extracted key file in Slot 1

[root@hacktheplanet ~]# cryptsetup luksOpen --test-passphrase --key-file=/testing-key-file.bin --key-slot 0 /dev/sdb3 && echo correct
No key available with this passphrase.
[root@hacktheplanet ~]# cryptsetup luksOpen --test-passphrase --key-file=/testing-key-file.bin --key-slot 1 /dev/sdb3 && echo correct
correct
[root@hacktheplanet ~]#

I generally think that if /crypto_keyfile.bin exists, the key file is specified in /etc/mkinitcpio.conf, and when you run mkinittcp -P Linux, it will be stored in initramfs. Therefore, I believe that the cause of this problem is that when /boot was decrypted, the root partition was decrypted using the key file stored in initramfs. Even if the password you typed at the prompt is invalid.

However, I don’t know without testing it with that SSD, so I edit /etc/mkinitcpio.conf and run mkinitcpio -p linux.

Nachlese · 25 April 2024 20:50

No worries. No problem at all!
I detected nothing of the sort.
… and even then, I’d just have ignored it - more than likely

For people to help you sort out your issue
it would be good if you could describe where you started from
(likely: (unencrypted) Mint was already installed)

Then you installed Manjaro - with some custom options like separate /boot and /
and different file systems for each one (ext4 for /boot , xfs for / )
and all encrypted on top of it.

Not sure how you convinced Calamares (the installer) to do that for you.

The result is something I do not want to debug - not without knowing what you did in sequence.

One system is unencrypted, the other one is encrypted.

The encrypted one needs to be in charge (what does Grub do, where is it installed …)

Why would you want or need a separate /boot (with ext4)
inside a fully encrypted system that is using xfs for it’s / file system?

Grub can boot from xfs, as far as I know.
Why make it separate? And different file systems?

Kajan0v3zk1 · 25 April 2024 21:35

Thanks to the community’s help, we were able to resolve the issue. My Manjaro on the SSD malfunctioned, so I recreated the same problem in VirtualBox, deleted the key file in /etc/mkinitcpio.conf, run mkinitcpio -P, and it magically worked. resolved.

# /etc/mkinitcpio.conf
~~Skip~~
#FILES=(/crypto_keyfile.bin)
FILES=()
~~Skip~~

of course. I’ll write it down just in case
First, create an area of 500GB (x2) by halving the SSD (1TB).
I then installed Manjaro on the first 500GB partition.
500MB /boot/efi
500MB encryption /boot
Approximately 1GB swap
Install system on encrypted root partition with 300 GB remaining

After installing Manjaro, I allocated Linux Mint in the remaining 500GB space as /boot space and / space respectively.

sdb                                                                                                                       
├─sdb1                                        vfat        FAT32       492A-F1F4 #                         
├─sdb2                                        swap        1           24bb60bf-e407-41cf-87a4-8c2eed7b5f60   
├─sdb3                                        crypto_LUKS 1     76fcdf94-8774-4376-b6cb-512b86fd0771 # 
├─sdb4                                        crypto_LUKS 1     a4ba34aa-34d1-47d1-80d4-80fb9ac669c9   #       
├─sdb5                                        ext4        1.0         de93062b-04a8-4f05-974a-b20e59225ce8 
└─sdb6                                        xfs                     3576b7bf-63af-49fa-b839-4d16db970c93

After installing Mint, grub was not touched except for update-grub.

Anyway, I’m relieved that the problem was resolved. It wasn’t like a serious Bug.

By rewriting /etc/mkinitcpio.conf and regenerating initramfs, it is now possible to start with a passphrase.

BG405 · 25 April 2024 21:36

My thoughts too … also, the partitioning order is a bit unusual*.

* Also, /boot/eif is even more so.

Kajan0v3zk1 · 25 April 2024 21:47

Why would you want or need a separate /boot (with ext4)
inside a fully encrypted system that is using xfs for it’s / file system?

I was surprised to hear that now. This is a bad habit I picked up a long time ago. At that time, I was using a PC that could not be booted without /boot until I used a UEFI-compatible PC.

Grub can boot from xfs, as far as I know.
Why make it separate? And different file systems?

I didn’t even know that GRUB supported XFS…I was clueless

Nachlese · 25 April 2024 21:54

You better fact check that - I could be wrong.
It’s just what I read … somewhere.
Not something I really know to be true.
(I have never ever used xfs in any way)

Kajan0v3zk1 · 25 April 2024 22:15

It seems that you can use XFS for /boot on Ubuntu… but it may not be very common…

Sources

https://unix.stackexchange.com/questions/175728/what-file-system-should-a-grub-2-boot-partition-use
https://askubuntu.com/questions/495994/what-filesystem-should-boot-be
https://superuser.com/questions/470688/why-100mb-ext2-boot-partition-recommended-for-linux

I think it is realistic to use a classic file system that can be used even with older implementations (the system of this OS, which was encrypted with Manjaro’s automatic installation function, was ext4).

system · 27 April 2024 10:15

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.