On Thu, Mar 19, 2020 at 11:53 AM Marius Schwarz <fedoradev@xxxxxxxxxxxx> wrote: > > Am 19.03.20 um 17:11 schrieb Michael Cronenworth: > > On 3/19/20 11:04 AM, Marius Schwarz wrote: > >> correct and thats the main issue, as long you have grub where you can > >> edit the kernel line to start in runlevel 1. > >> This makes the encryption null and void. > > > > Adding a grub password will prevent those without it from editing your > > boot parameters. By default you can still boot without the grub > > password. Does that help? > > It would solve a problem. > > - does it prevent updates ( after booting into rl 5 ) of grub? > - where is the passcode stored? grub.cfg or user.cfg contains the hashed password https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Password_protection_of_GRUB_menu https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sec-protecting_grub_2_with_a_password But if the attacker has physical access to the computer, they can mount /boot/efi or /boot where this file is stored; and remove the password requirement. The GRUB password protection workflow protects the kiosk use case, where there is no physical access. Not a stolen laptop. I think what you'd want for the stolen laptop use case is an encrypted $BOOT, which GRUB does support: The first grub.cfg is unencrypted, and provides strictly for unlocking a LUKS1 (no LUKS2 support yet) $BOOT volume, and then using 'configfile' command to read a second "real" grub.cfg on the encrypted $BOOT, which also contains BLS snippets, and kernel+initramfs. Since a passphrase is required to even read these files, in order to boot the installed system, I'm not sure it's necessary to also lock down the command line. (Also, the setup details differ considerably between UEFI and BIOS.) The out of the box UX, whether GRUB edit lockdown or encrypted $BOOT, would be terrible. It requires a sophisticated user to understand, maintain, and troubleshoot such a setup. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
