Tomster/Arch-Setup-Script
1
0
Fork 0
mirror of https://github.com/tommytran732/Arch-Setup-Script synced 2024-11-22 01:21:34 -05:00
Code

Update README.md

Browse Source
This commit is contained in:
TommyTran732 2021-07-25 11:08:41 +00:00 committed by tommytran732
parent 7eb9705da5
commit 0c12fcc234
No known key found for this signature in database
GPG Key ID: 060B29EB996BD9F2
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
README.md
View File

@ -17,15 +17,6 @@ The Secure Boot script can be runafter you have rebooted into the system to auto
Currently, there is an problem where GRUB requires tpm.mod to be included for signature verification, but if tpm.mod is included and the TPM is enabled it will also attempt to do Measured Boot, breaking the Arch Linux snapshots menu created by grub-btrfs. I have yet to find a solution for this issue. Currently, there is an problem where GRUB requires tpm.mod to be included for signature verification, but if tpm.mod is included and the TPM is enabled it will also attempt to do Measured Boot, breaking the Arch Linux snapshots menu created by grub-btrfs. I have yet to find a solution for this issue.
### LUKS1 and Encrypted /boot (Mumbo Jumbo stuff for anyone who's wondering why)
This is the same setup that is used on openSUSE. One problem with the way Secure Boot currently works is that the initramfs and a variety of things in /boot are not validated by GRUB whatsoever, even if Secure Boot is active. Thus, they are vulnerable to tampering. My approach as of now is to encrypt the entire /boot partition and have the only that is unencrypted - the grubx64.efi stub - validated by the firmware.
Ideally, I could use GRUB's GPG verification for the initramfs and its configuration files and what not, but then I need to create hooks to sign them everytime they get updated (when a new initramfs gets generated, when grub-btrfs.path gets triggered, when grub gets updated and its config files change, etc). It is quite a tedious task and I have yet to implement or test this out.
As for why LUKS1 is used, GRUB 2.06 does not work nicely with LUKS2 yet. grub-install will not make GRUB auto detect the LUKS2 partition, and GRUB itself does not support Argon2id (cryptsetup default) as of now anyways. In my opinion, it makes little sense to use GRUB with LUKS2 in its current state, thus I am using LUKS1 to avoid the headache for the time being.
You may also see an a keyfile being created by the script and stored at /cryptkey. This is to avoid getting 2 encryption password prompts (one for GRUB to decrypt the disk so that it can get to the kernel, the initramfs and configuration files and one for the kernel itself to start up the rest of the boot process). As the key resides on an encrypted partition (and so does the initramfs that stores a copy of it), security risks should be minimal. The only time an attacker would have access to it is when they have root, at which point you have a much, much more serious proble). The procedure I am using is describe at https://en.opensuse.org/SDB:Encrypted_root_file_system.
### Changes to the original project ### Changes to the original project
1. Encrypted /boot with LUKS1 1. Encrypted /boot with LUKS1
2. SUSE - like partition layout and fully working snapper snapshots & rollback 2. SUSE - like partition layout and fully working snapper snapshots & rollback
@ -66,3 +57,12 @@ The partition layout I use rallows us to replicate the behavior found in openSUS
| 15 | @/var_lib_gdm | /var/lib/gdm | Encrypted BTRFS (nodatacow) | | 15 | @/var_lib_gdm | /var/lib/gdm | Encrypted BTRFS (nodatacow) |
| 16 | @/var_lib_AccountsService | /var/lib/AccountsService | Encrypted BTRFS (nodatacow) | | 16 | @/var_lib_AccountsService | /var/lib/AccountsService | Encrypted BTRFS (nodatacow) |
| 17 | @/cryptkey | /cryptkey | Encrypted BTRFS (nodatacow) | | 17 | @/cryptkey | /cryptkey | Encrypted BTRFS (nodatacow) |
### LUKS1 and Encrypted /boot (Mumbo Jumbo stuff for anyone who's wondering why)
This is the same setup that is used on openSUSE. One problem with the way Secure Boot currently works is that the initramfs and a variety of things in /boot are not validated by GRUB whatsoever, even if Secure Boot is active. Thus, they are vulnerable to tampering. My approach as of now is to encrypt the entire /boot partition and have the only that is unencrypted - the grubx64.efi stub - validated by the firmware.
Ideally, I could use GRUB's GPG verification for the initramfs and its configuration files and what not, but then I need to create hooks to sign them everytime they get updated (when a new initramfs gets generated, when grub-btrfs.path gets triggered, when grub gets updated and its config files change, etc). It is quite a tedious task and I have yet to implement or test this out.
As for why LUKS1 is used, GRUB 2.06 does not work nicely with LUKS2 yet. grub-install will not make GRUB auto detect the LUKS2 partition, and GRUB itself does not support Argon2id (cryptsetup default) as of now anyways. In my opinion, it makes little sense to use GRUB with LUKS2 in its current state, thus I am using LUKS1 to avoid the headache for the time being.
You may also see an a keyfile being created by the script and stored at /cryptkey. This is to avoid getting 2 encryption password prompts (one for GRUB to decrypt the disk so that it can get to the kernel, the initramfs and configuration files and one for the kernel itself to start up the rest of the boot process). As the key resides on an encrypted partition (and so does the initramfs that stores a copy of it), security risks should be minimal. The only time an attacker would have access to it is when they have root, at which point you have a much, much more serious proble). The procedure I am using is describe at https://en.opensuse.org/SDB:Encrypted_root_file_system.