Earlier quoted context omitted.
That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…
Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.
Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
91–100 of 180 posts
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#92Earlier quoted context omitted.
The 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. I tend to think the Linux on the desktop thing is a bit of a diversion, but this issue and Poettering's response certainly lend weight to the concerns many have raised about systemd. What happened to defence in depth? Even if your users…
Well, I could see a problem occurring if Poettering decided not to represent efivars as files. Many people would claim that Systemd is trying to get rid of the Unix philosophy and force everyone to use the software if they want to keep up. After all, so many people are already complaining that Systemd uses a binary format to store logs.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#93Earlier quoted context omitted.
That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…
Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.
My personal opinion is that, for the use case of a single-user machine (i.e., "Linux on the desktop"), the traditional UNIX root isn't a useful concept. What's actually sensitive is your files, your saved passwords, your browser cookies, your emails, etc.; the ability to reconfigure drivers or replace OS components is only a problem because it allows all of those things to be compromised. Instead of throwing roadblocks in the way of root (remount ro, expose it as something more complicated than a filesystem so innocent users aren't tempted to look at it, etc.), let's take all the stuff that users should be able to do and make it accessible by nonroot, and take all the stuff they shouldn't be able to do and put it in the realm of automation.
UEFI has a pretty reasonable concept here, of a distinction between "boot" and "runtime" configuration; the BSDs have a conceptually similar idea of the securelevel. The idea is that if you're around during the boot, you might be interested in reconfiguring what the machine is doing, but as soon as you're out, you permanently abjure any further ability to reconfigure that. If we take a variant on that, that the OS doesn't abjure those capabilities as a whole but instead reserves them for itself, disabling all user-controlled ability to change things, I think we get very far. You can install new software, but not change the trusted sources for software. You can apply firmware updates via an existing cronjob, but not make arbitrary changes to firmware variables. If you want to do any of that, you have to reboot and enter a special setup mode. Apart from protecting against simple human error, this also serves as a very effective protection against malware: non-OS software simply has no ability to do unwanted things.
Then let's use UNIX users (which are a pretty solid isolation technique) to isolate things like your banking info from your Flash-requiring music service.
Chrome OS, incidentally, has this concept of things the OS can do that the user has no interface to, and Chrome OS is basically the most successful Linux on the desktop, so.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#94Earlier quoted context omitted.
If you mount efivarsfs read-only, efibootmgr can't make your system bootable. So at a minimum, you can't just remount the filesystem read-only; you need distribution integration so efibootmgr can still write to it. There's no point in mounting efivarsfs read-only; you might as well not mount it at all.
(Honest question, I lack hardware to check this on myself:) What do non-systemd systems do about this?
Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades.
GRUB2 seems to use efibootmgr to write stuff to EFI, and efibootmgr appears to lack a "detect if efivarfs is mounted ro and temporarily mount it rw" switch, so you have to do that manually too.
Gentoo's Genkernel-next doesn't seem to do anything at all with EFI.
Dracut (one of RedHat's initrd management tools) looks like it reads from efivarfs, but does not write to it. (But there's a lot of code in Dracut, so it's entirely possible I missed something.)
It's not entirely clear to me that you can't use BIOS boot with a GPT-formatted disk if your bootloader supports that sort of thing. It's also not clear to me whether or not chainloading from GRUB into Windows is supported with a BIOS/GPT partitioning scheme.
Regardless, it's a pity that the UEFI design committee apparently thought that requiring one to write data into the motherboard's persistent storage in order to boot into a OS was a reasonable thing to do.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#95Earlier quoted context omitted.
Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.
The point is that that would offer no benefit. A root user can just mount it rw again in a single call.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#96Earlier quoted context omitted.
Linux is important on dekstops to thrive. I've successfully transitioned my parents to Linux. What I got? Deser maintainance, more reliability, everything just works for them. And of course, sticking to proprietary solutions in a long run would be rather a sick idea.
Linux derivatives rule the mobile space spo in essence it won really big. The desktop is not that impoortant. And so many of its paradigms are quite dated compared to the mobile experience.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#97Earlier quoted context omitted.
The new Citibank ATMs that take the chip card hold onto it until after you've taken your money. I already accidentally left my card in a machine after taking the cash.
Wow, that's some bad UI. Wells Fargo ATMs require you to take your card before it gives you the money.
I know, I was one of those before my bank got newer, smarter ATMs.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#98Earlier quoted context omitted.
(Honest question, I lack hardware to check this on myself:) What do non-systemd systems do about this?
FreeBSD has an efi library that's used in early boot to handle this instead. To be honest, with the structure of UEFI, exposing it as a filesystem is problematic at best. A filesystem just hides too much data from you -- errors, the reason a call to setting a variable failed, etc. Not everything is a file, and shoehorning things in to try to pretend just doesn't work.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#99Earlier quoted context omitted.
That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…
Root needs access, but creating a pseudo-filesystem to access an area of the system with metadata, etc that doesn't map well to a filesystem, especially given the number of very buggy implementations of UEFI out there is just asking for trouble. There are properties that have settings to be visible only certain times during the boot process, there are settings that involve changing guids, etc. Access is better served…
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#100Earlier quoted context omitted.
If you mount efivarsfs read-only, efibootmgr can't make your system bootable. So at a minimum, you can't just remount the filesystem read-only; you need distribution integration so efibootmgr can still write to it. There's no point in mounting efivarsfs read-only; you might as well not mount it at all.
(Honest question, I lack hardware to check this on myself:) What do non-systemd systems do about this?