Slashdot Mirror
Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com)
An anonymous reader writes: For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?
Because this sounds so horribly broken it isn't funny.
Actually, no, it's actually quite funny in a big giant "WTF" kind of way.
Lost at C:>. Found at C.
They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.
There are two parties to be frustrated with: /dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.
-Firmware developers, for not being resiliant in the face of such shenanigans
-The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm
XML is like violence. If it doesn't solve the problem, use more.
Seems to me that this can be alleviated with selinux. Deny all write access to those paths except when in an explicit context, which the few tools that need that access will have, and even root will have to newrole into to use.
I'm curious if booting from BIOS/MBR would do the trick. Higher end BIOSes still have the ability to not use UEFI and just do things the old fashioned way. IIRC, this doesn't expose the UEFI variables at all, providing some brick-resistance. Of course, you lose Secure UEFI functionality, making MBR attacks possible, but it is taking the lesser evil.
Yepp, Some package managers are on crack too often.
Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.
We suffer more in our imagination than in reality. - Seneca
I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed. I couldn't believe it. RMSes worst nightmares come true, today. Un-fucking-believable.
UEFI is just another machiavellian attempt at controlling our hardware from start to finish. It's basically the old TCPA bullshit repackaged. How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me. I honestly am of the opinion that those who designed this freakin' insane UEFI BIOS crap and peddle it should be brought before court for malicious malpractice and willfully undermining computer security.
UEFI in my book is definitely a reason not to buy the hardware using it.
BTW: How come no one get's worked up about that? Everyone is pissing their pants about systemd, but UEFI doesn't get half as much bad press. I remember the TCPA uproar - that was a good one. How about now?
We suffer more in our imagination than in reality. - Seneca
While that may be true, most systems don't use SELinux, and for fairly good reason if you ask me. I've tried a couple of permutations on the idea, and having several parallel security systems has never really come out as a good thing in the end. Especially one as complex as SELinux.
While that may be true, it could be considered an attack vector. We have been focusing on accidental corruption, but it makes for a pretty mean thing to do to some poor saps hardware. Resiliency in the face of such a condition is not too unreasonable, it's just a test case that hasn't really been pursued to date. UEFI having missing configuration should be easy enough for code to cope with.
XML is like violence. If it doesn't solve the problem, use more.
Having had a less than ideal misttyped rm command go awry on me at one time, I now *always* preface any initial intent to rm anything from the shell with 'echo'. I do this whether or not I am root, look at the output, and if it all looks good, I then repeat the command without 'echo' by hitting the up arrow and deleting the first word.
File under 'M' for 'Manic ranting'
first
rm -rf /first/*.*
By the by, the above 'code' snippet may well brick a *nix box - use at your own risk. I saw first-hand that doing an rm -rf *.* was perfectly capable of blowing away an entire install (including all mounted devices), no sweat - at least as late as 2006 when a junior admin I once worked with made that rather horrendous typo in his regex...
But overall, why the hell is this news? I mean, every OS has this problem (see also the ancient deltree, or the newer rd /s, or getting stupid with the GUI Disk Utility in Windows or OSX, etc.)
Boys and girls, this is why you don't give ordinary folks admin/root/wheel/whatever privileges, eh?
Quo usque tandem abutere, Nimbus, patientia nostra?