this post was submitted on 28 Aug 2023
33 points (100.0% liked)

Linux

48182 readers
2022 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

So basically, my setup has everything encrypted except /boot/efi. This means that /boot/grub is encrypted, along with my kernels.

I am now attempting to get secure boot setup, to lock some stuff, down, but I encountered this issue: https://bbs.archlinux.org/viewtopic.php?id=282076

Now I could sign the font files... but I don't want to. Font files and grub config are located under /boot/grub, and therefore encrypted. An attacker doing something like removing my hard drive would not be able to modify them.

I don't want to go through the effort of encrypting font files, does anyone know if there is a version of grub that doesn't do this?

Actually, preferably, I would like a version of grub that doesn't verify ANYTHING. Since everything but grub's efi file is encrypted, it would be so much simpler to only do secure boot for that.

And yes, I do understand there are security benefits to being able to prevent an attacker that has gained some level of running access to do something like replacing your kernel. But I'm less concerned about that vector of attack, I would simply like to make it so that my laptops aren't affected by evil maid attacks, without losing benefits from timeshift or whatnot.

I found the specific commit where grub enforces verification of font files: https://github.com/rhboot/grub2/commit/539662956ad787fffa662720a67c98c217d78128

But I don't really feel interested in creating and maintaining my own fork of grub, and I am wondering if someone has already done that.

you are viewing a single comment's thread
view the rest of the comments
[–] moonpiedumplings@programming.dev 1 points 1 year ago (1 children)

Sounds like cope to me. You don't get to tell an attacker which component they can attack when you have misconfigured your security guards.

There is only a single thing on my system unencrypted: the grubx64.efi binary. This binary is verified via secure boot. Unless an attacker can break luks2 encryption, they cannot get to anything else.

I keep the LTS kernel around for that

Did you read your own post? The lts kernel was affected too. That's why I used it as an example.

anyway, a simple chroot should allow me to fix any problems.

You could also just nab the older kernel from the archive or something, if your system still boots. But I don't want to have to do that. I have better things to spend my time on then going through the pain of disabling all my security features so I can chroot into an encrypted system.

[–] hottari@lemmy.ml -1 points 1 year ago

There is only a single thing on my system unencrypted: the grubx64.efi binary. This binary is verified via secure boot. Unless an attacker can break luks2 encryption, they cannot get to anything else.

I don't know enough about the subject of a secure grub to tell you how wrong you are.

Did you read your own post? The lts kernel was affected too. That’s why I used it as an example.

Yes I did. It was a terrible example. As all I would need to know was the last working version for TPM. Regression in LTS does not factor in this equation.

And most importantly, it would not stop me from booting.

You could also just nab the older kernel from the archive or something, if your system still boots. But I don’t want to have to do that. I have better things to spend my time on then going through the pain of disabling all my security features so I can chroot into an encrypted system.

You think you are saying something smart here but I assure you, you couldn't be more conceited. You are maintaining a patch of grub for a bug that grub has no idea it exists. And you claim not to have time to fix your installation...