Re:Systemd mounted efivarfs read-write, allowing motherboard...
by snuxoll on Saturday January 30, 2016 @03:38AM
(#11001130)
Did Lennart have anything to do with the actual efivars implementation in the kernel? If so, then yeah, shame on him by all means. I agree it's a broken abstraction, but it's what the kernel developers decided on (and they sure like making system configuration available with filesystems, see sysfs and procfs).
Ultimately access is needed to even configure the bootloader, and right now that means it needs to be mounted RW. Let's go yell at the kernel developers instead of taking it out on systemd for using a virtual filesystem instead of a syscall.
Re:Systemd mounted efivarfs read-write, allowing motherboard...
by icebraining on Sunday January 31, 2016 @06:49PM
(#11008734)
By the way, here's the author of the kernel module in question, talking about this issue:
Re:Systemd mounted efivarfs read-write, allowing motherboard...
by snuxoll on Monday February 01, 2016 @12:34PM
(#11013374)
I'm really glad he's speaking out on the issue, Matt is a smart guy (I used to talk with him frequently on IRC) and it's sad to see many of the same people trying to act like they know better than him in that twitter thread. There's no easy fix to this issue, and regardless of whether an rm -rf / can hose your system there's bigger issues at stake with malicious actors that a stupid bandaid like that won't fix.
Re:Systemd mounted efivarfs read-write, allowing motherboard...
by digi_owl on Saturday January 30, 2016 @10:14AM
(#11002068)
Here is the thing, one day systemd overrides a kernel default without warning because of "best practices", another day they leave it alone even if it is basically a cocked gun aimed at the admins foot.
Re:Systemd mounted efivarfs read-write, allowing motherboard...
by C0DEHERO on Friday January 29, 2016 @09:37PM
(#11000220)
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...
by Silhouette on Saturday January 30, 2016 @02:29AM
(#11000946)
My view is that treating everything in the universe as part of the same filesystem hierarchy is one UNIX philosophy we should have dispensed with long ago. I don't think it makes sense to project the same abstractions we use to represent file storage onto other aspects of a system just because they also happen to provide some information and then to treat everything as part of a huge, monolithic, homogeneous structure. The Filesystem Hierarchy Standard is very complicated already -- a discussion for another time, perhaps -- but what does something like "rm -rf /" (or any other actual file/directory manipulation) even mean at this point? I think reverence for some of these ideas just because they are "the UNIX way" is holding the industry back.
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 are all perfectly competent, with this sort of arrangement you're one vulnerability away from having bricked boxes, not just one vulnerability away from reimaging and restoring from backups.
What happened to making systems safe by default? There is no need to make this kind of system so fragile.
What happened to using the right tool for each job? The obsession with making everything look like a file that lives under the same global file system hierarchy causes endless problems, and it's never been entirely clear to me what benefits it's supposed to offer in return. It's interesting that Poettering remarked on exposing /dev/sda as root as well, because it's another excellent example of how broken this model is.
What happened to minimising trust? Of course it's crazy that any hardware/firmware actually allows itself to be permanently broken by a software error like this, but the software should not assume the hardware/firmware will take responsibility for providing any necessary safeguards.
Ultimately, this is just bad engineering and bad UI. It can result, and reportedly has resulted, in serious damage. No amount of dressing it up will change that, and the root cause of the problem should be fixed.