Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
1–10 of 180 posts
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#2That's a dreadful response from Pottering.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#3To be fair, userspace access to these variables is required in order to manage EFI boot. Having them there to be deleted (by root!) accidentally is probably bad, but this isn't a meaningful security fix.
The real crisis here is that modern firmware is developed in an environment so fragile and isolated that it's simply unable to recover from configuration that is "wrong".
I had a laptop that I bricked about two years ago by accidentally wiping out the partition table on the soldered-down storage.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#4These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/.
Systemd hate is en vogue these days so they are an easy and common target. Why no invective towards the kernel that actually implements EFI-as-a-filesystem?
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#5> (note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro")
He's suggesting that not mounting it as read-only by default will break a few things like grub-install, but promptly suggested editing /etc/fstab to mount it read-only by default.
So... his own solution to the problem is to mount it as read-only.
The hard drive analogy is ridiculous because while you can lose data you cannot brick your hard drive or computer by erasing it. There are ways to brick a hard drive by corrupting the firmware but there are very specific tools like "hdparm" that you have to use to do it, not an everyday command like "rm".
This makes me wonder why Linux only has a single "root" user rather than multiple types of administrators. Windows, for example, has Administrator, which can do nearly everything, but some files and processes are protected under SYSTEM or TrustedInstaller. If you REALLY want to, you can still remove those files by changing ownership, or launching a command prompt with SYSTEM permissions, but it does add a significant hurdle to doing things that could cause significant damage.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#6To be fair, userspace access to these variables is required in order to manage EFI boot. Having them there to be deleted (by root!) accidentally is probably bad, but this isn't a meaningful security fix. The real crisis here is that modern firmware is developed in an environment so fragile and isolated that it's simply unable to recover from configuration that is "wrong". I had a laptop that I bricked about two years…
Yes but almost all use cases allow you to set them immutable or remount by default. The management of them can be done with a couple commands.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#7To be fair, userspace access to these variables is required in order to manage EFI boot. Having them there to be deleted (by root!) accidentally is probably bad, but this isn't a meaningful security fix. The real crisis here is that modern firmware is developed in an environment so fragile and isolated that it's simply unable to recover from configuration that is "wrong". I had a laptop that I bricked about two years…
Userspace access. Not access via yet another pseudo-filesystem. Especially not access via yet another pseudo-filesystem automatically mounted read/write at boot time. GRUB works just fine on other systems that don't have a pseudo-filesystem for EFI access.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#8These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these day…
Yeah but you can normally recover from that without a soldering iron. Badly implemented EFI is out there.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#9These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these day…
The issue here is actually bricking the device. It's not your standard "do we let people hang themselves or limit the user's capabilities" debate.
A filesystem is a perfectly reasonable way to implement access to the EFI vars.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#10The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best.
Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ((note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro") is a better idea than mounting it read-only, and requiring those few who need to write these variables to do some extra work by remounting it read-write.