Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

github.com

Post reply on HN
Print view View original

141–150 of 180 posts

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#141

Post by mikeash »

snuxoll wrote: post #102
mikeash wrote: post #12

Earlier quoted context omitted.

I don't think this is meant to be a security fix, it's just meant to make it so you can't accidentally break your hardware with what seems like an unrelated filesystem command. I agree that the stupid firmware is ultimately to blame, and mounting this stuff read-write is a fairly reasonable initial decision. But given the existence of this stupid firmware, the resistance to implementing an easy mitigation by mounting…

Technically, denial of service is a security issue - I have modern servers that boot via UEFI (since GPT is required to support large disks), hopefully with less buggy implementations but if someone manages to get root on a server they could totally kill the hardware. Having to reinstall an OS because some script kiddie decided to `rm -rf --no-preserve-root /` your server bites, but actually bricking the system requi…

Regarding your edit, exactly. The issue could be considered a security issue, but this fix is not a security fix. A security fix would be something like only allowing touching EFI during startup and then somehow securely and permanently disabling that ability until the next reboot, or a physical write-protect switch on the computer.

Or EFI firmware not being so stupid, but we know that's not going to happen.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#142

Post by mikeash »

GhotiFish wrote: post #84
mikeash wrote: post #14

Earlier quoted context omitted.

Sometimes people run rm -rf / just for fun before reformatting a system, just to see what happens. Given that its purpose in life is to delete files, it stands to reason that running this command on a system which contains no important data is OK. A default configuration which makes this command destroy hardware is not reasonable.

It's funny you mentioned that rm's purpose in life is to delete files. I'm reminded of a common saying in the unix world. Everything is a file.

This is a good example of why you shouldn't take that saying too far.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#143

Post by krylon »

pdkl95 wrote: post #135
krylon wrote: post #124

Earlier quoted context omitted.

Oh my, that is bad indeed. Apart from the two-item sample of personal experience I am kind of torn about systemd - some of the problems it attempts to address are real, and addressing these in general seems like a good idea. The way it does so, however, sometimes (I am being deliberately vague here) brings along some problems of its own.[1] And the further systemd adoption and systemd's mission creep go along, the ha…

> I have not experienced any of these problems myself That's the problem any time[1] a system is designed around ideological purity. Someone invents something clever that works most of the time for most people (with varying definitions of "most"), so they try to apply it everywhere. As no idea can account for everything[2], this sooner or later the inflexibility of the theory meets the variation of realty and some ty…

Agreed. Which is why I said On the other hand a certain amount of skepticism and criticism is very much in order.

The problems systemd tried to address are real, and some of the ideas behind it are appealing. But the way it attempts to replace several important pieces of the system at once, and the way it is being forced on people in a "eat it or leave it"-style feels uncomfortable.

Part of what made Unix what it is today is the idea to build a system that might be very far from perfect but that is easy to improve in small, incremental steps so one quickly gets a feeling for what works well and what does not.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#144

Post by SEJeff »

Ao7bei3s wrote: post #132
pjmlp wrote: post #113

Earlier quoted context omitted.

Lots of GNU/Linux distributions used to it by default, has it changed?

None I currently use (just tested with bash* on: Debian, Centos, Fedora, OpenWRT) or have used in the past few years (Arch) has it. I don't remember anything about my time with SUSE and Ubuntu, thats way back. * I normally use zsh with grmlzshrc and nearly no customization (which is why I love grmlzshrc -- usable defaults), which warns for `rm -rf foo/*` but not for `rm -rf foo`.

Redhat based distros absolutely do enable alias rm='rm -i' out of the box, but only for the root user. As a career SysAdmin, that seems like a good compromise. If you want to take the safety net off, you can escape out the alias (or any alias) with a slash i.e.:

\rm -rf somedir

Yet by default, if you don't include the "\", you get rm -i

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#145

Post by andmarios »

milkey_mouse wrote: post #89
andmarios wrote: post #56

One day I broke my laptop's boot list, so I went to add a new efi boot entry. I couldn't and thought it was due to my inability to find a proper usb bootable media with efi support since you can't access efi-vars if you boot from bios. Turns out linux used to store crash-dumps inside efi-vars, so mine were full and new entries couldn't be written. Good thing /sys/firmware/efi/vars/ was mounted rw, thus a `rm -rf /sys…

Breaking your laptop's boot list will happen more often with it mounted RW anyway. So it's good it fixed it for you, but I doubt the number of cases it's fixed something/been useful outnumbers the cases where someone bricks their system using what is probably the most repeated Linux command on the internet: rm -rf /.

The reason the efi's boot list was broken was because I wanted to replace a HDD. The laptop has 2 HDDs, I removed them and booted with the new, empty disk for an experiment before adding back my system disk. UEFI thought is was appropriate to remove the non-existing disks' entries from its list and thus I couldn't boot anymore.

Anyway, I don't think this is a systemd bug. The /sys interface comes from the kernel and whether you will access efi vars depends on your kernel configuration. There is the older module (I believe _efivars_ if it isn't compiled as built-in) and the newer (I believe _efivarsfs_).

I've done my fair share of systemd bashing but here we have:

  1. Broken and/or naive EFI implementations
  2. Linux kernel's default choices (expose efivars as rw)
  3. Distro's choices (compile kernel with said modules as built-in)
And we give the fault to systemd. Every other init system out there does the same.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#146

Post by digi_owl »

snuxoll wrote: post #105
Silhouette wrote: post #44

Earlier 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…

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 mounte…

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 bricking via 'rm'

#147

Post by chris_wot »

jhkaghjkga wrote: post #140
chris_wot wrote: post #138

Earlier quoted context omitted.

Uh no. Not tradition: experimentation, learning, having fun, curiosity, and all the things that make for a proficient sysadmin.

To quote the original post: > Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that". So, yes, "tradition".

Actually, no. You might want to experiment on a test system to see what "tradition" actually does. Then you, you know, learn the consequences because you are, you know, curious to understand the result of the operation. And many people find this, well, fun. Normally people who do this sort of thing exhibit the traits that make them a good sysadmin because they are verifying Unix-lore to ensure that they aren't just following some sort of cargo cult methodology.

Hope that helps.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#148

Post by Ao7bei3s »

SEJeff wrote: post #144
Ao7bei3s wrote: post #132

Earlier quoted context omitted.

None I currently use (just tested with bash* on: Debian, Centos, Fedora, OpenWRT) or have used in the past few years (Arch) has it. I don't remember anything about my time with SUSE and Ubuntu, thats way back. * I normally use zsh with grmlzshrc and nearly no customization (which is why I love grmlzshrc -- usable defaults), which warns for `rm -rf foo/*` but not for `rm -rf foo`.

Redhat based distros absolutely do enable alias rm='rm -i' out of the box, but only for the root user. As a career SysAdmin, that seems like a good compromise. If you want to take the safety net off, you can escape out the alias (or any alias) with a slash i.e.: \rm -rf somedir Yet by default, if you don't include the "\", you get rm -i

You're right about RedHat, sorry.

.bash_history says I accidentally added `-f` on that host. I should have just checked with `which` instead of trying it out. Oops.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#149

Post by uxcn »

tdy721 wrote: post #128
threatofrain wrote: post #116

Earlier quoted context omitted.

That appears to validate my belief that only Google can competitively take the Linux kernel and build atop it a software stack known as a desktop/mobile/user operating system. And if my assertion that intention prediction and voice search will be competitive features for users, features that rely on mass data collection and expensive top talent, then I think organizations like Canonical or RedHat will fall behind in…

I tend to mix up Linux and Unix and that might be the issue here... But isn't the `Apple Garden` (OSX and iOS) an example of a desktop/mobile/user operating system built on Linux? Apple's no M$, but they are certainly competitive.

No, OSX is based on NeXT, which was based on Mach, and BSD. As far as I know, iOS is proprietary.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#150

Post by uxcn »

threatofrain wrote: post #131
tdy721 wrote: post #128

Earlier quoted context omitted.

I tend to mix up Linux and Unix and that might be the issue here... But isn't the `Apple Garden` (OSX and iOS) an example of a desktop/mobile/user operating system built on Linux? Apple's no M$, but they are certainly competitive.

It's entirely possible that Apple takes code or inspiration from the Linux software project, but I think it's better to say that OS X is Unix based . Even if Linux and Darwin hail from Unix roots, at some point, I think they become separate projects with separate interests and fates. What's good or bad for one doesn't have to be the same for the other. When I think of what organizations will be competing on machine-l…

> It's entirely possible that Apple takes code or inspiration from the Linux software project, but I think it's better to say that OS X is Unix based.

Apple can't take code from Linux as the code is GPL licensed. OSX is largely based on NeXT and BSD. Linux and OSX are both POSIXish though.

Post reply on HN