14 ms·
Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
- chris_wot 11y agoThat's a dreadful response from Pottering.
- ajross 11y agoTo 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.
- fweespeech 11y agoYes 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.
- Sanddancer 11y agoUserspace 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.
- mikeash 11y agoI 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 it read-only is insane. I can't understand why there are any responses besides "oh shit, we'd better change this."
- snuxoll 11y agoTechnically, 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 requiring a board replacement is scary. (Of course, they could technically be a jerk and flash your UEFI EEPROM, but most servers have a backup they will restore from in case the primary has been corrupted). EDIT: Though, now that I think about it, this is still only going to stop users from hosing their systems. A malicious user could still run an arbitrary binary or kernel module that hoses the UEFI variables as well. Or by modifying the UEFI boot config to load some other custom UEFI binary to hose it... firmware vendors really just need to get their crap in gear, software (even running in UEFI boot services mode shouldn't be able to hose it).
- mikeash 11y agoRegarding 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.
- mmastrac 11y agoThese 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?
- voltagex_ 11y agoYeah but you can normally recover from that without a soldering iron. Badly implemented EFI is out there.
- cmhamill 11y agoThe 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.
- dkarapetyan 11y agoBecause everything is a file in unix derivative land. That is a common accepted practice at least but optimizing for the common case here is the right thing to do. How often do people need to manage EFI things through the filesystem and how much of an inconvenience is it to have the initial mount be read-only? The answer is obvious to me because I know people run `rm -rf` often enough that having a safeguard in place is the right thing to do.
- SFjulie1 11y agoA file maybe, a filesystem no. You can't 'ls' your network connections. And for tricky API that does not match the filesystem view we have the fnctls.
- dkarapetyan 11y ago
- Osiris 11y ago> (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.
- rando3826 11y agoIn linux, there is the immutable file attribute which won't let root rm the file without first changing it with chattr.
- ploxiln 11y agoFile attributes need to be implemented by the filesystem. efivars is a pseudo-filesystem which does not implement them. It could, but that is one of the more needlessly complicated solutions...
- C0DEHERO 11y agoTo be fair, you could make a distribution that works this way (or you could modify a current install). Simply make critical files belong to root, make files that are fairly important (config files) belong to a special user, and make user files belong to the user. This way, you can do day-to-day system administration with a more powerful but still limited user, while performing critical operations, such as installing a bootloader, as root. NixOS sort of does something similar, although not necessarily for the reason of preventing breakage. Any regular user can install packages for his/her own environment, which the daemon installs in the package directory that belongs to "nixos" You still need to use root for system configuration, unless the "configuration.nix" could also be chowned to the "nixos" user.
- Someone 11y agoThe 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.
- LoSboccacc 11y ago"let's make everything a filesystem so it's dead easy to hang yourself from userland tools"
- cmiles74 11y agoLet's make everything a filesystem... so that they are easy to access and modify. Anyone can "rm -rf" anything, that doesn't mean that they should.
- LoSboccacc 11y agothat's a pretty weak argument. fault is in the firmware, but design of thing is important. it's why ATM gives the card back before the money. they don't just tell the user to suck it up. they implement good, safe best practices.
- jasonmoo 11y agosensible defaults
- deleted 11y ago[deleted]
- Sanddancer 11y agoUnless you're doing something super screwy, GRUB, the excuse for this backwards default, doesn't even need access to UEFI. UEFI booting looks for a file in a FAT-formatted partition of a hard disk with a specific ID -- C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT disks and 0xEF for MBR disks. All EFI does is to look for a file BOOTX64.EFI on that partition. There's no need to muck around the UEFI settings for this, it Just Fucking Works.
- JoshTriplett 11y agoOnly removable disks use bootx64.efi, though some (but not all) BIOSes will look for that on fixed disks too. efibootmgr needs access to efivarsfs to configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on bootx64.efi on the EFI system partition will break on some devices, and will overwrite the Windows bootloader (and conversely, Windows doing so will render Linux unbootable).
- Sanddancer 11y agoThe standard is for EFI to look for that partition on all disks, even hard disks. If there are a few broken systems that do otherwise, they could use other methods, but keeping things mostly standardized seems like the best way to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD does it, etc. Mucking around with it doing otherwise is just asking for problems.
- JoshTriplett 11y agoThe EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).
- Sanddancer 11y ago
- alexandrerond 11y agoHow long before someone realises that grub could also be made part of systemd... cringes
- simoncion 11y ago> How long before someone realises that grub could also be made part of systemd... https://wiki.archlinux.org/index.php/Systemd-boot https://wiki.archlinux.org/index.php/Systemd-boot
- alexandrerond 11y agoThis is why I didn't even want to google it... ignorance is bliss. Thank you, i guess...
- endgame 11y agoAnd that's the sort of thing that could easily sneak into the `curl http://some/url http://some/url | sudo bash`-style of installs that are popular these days.
- moonbug 11y agoGood.
- snuxoll 11y agoI could do it in an RPM post-install script too if it will get people to stop whining about running arbitrary scripts. All software you install on your system through binaries is potentially suspect to an extend. Sure, I trust the Fedora build system to do the right thing, so I can with some certainty assume anything in the Fedora Collection or EPEL is "safe" - but when I need to install 3rd party software to get my video card working I can throw all that out the window. Be sane when testing any binary you install, at least with RPM's or DEB's I can verify the GPG key of the vendor - assuming they bother to use one at all... piping scripts directly from curl to bash is bad because of the potential of the stream ending early and leaving in an inconsistent state, that's the only thing that is notable worse versus installing a package (and can be worked around by downloading it first, THEN executing it).
- deleted 11y ago[deleted]
- chris_wot 11y agoGiven you need to be root to install software on an Ubuntu system, a deb could do that also.
- cnvogel 11y agoAre you arguing about malicious attempts to mess up, or brick, your computer, facilitated by efivars presenting an interface accessible by simple shell scripts? Well... If there would be an api requiring, for example, a special syscall (or maybe even uglier, an mmap of /dev/men), I'm 100% percent sure that the default install of all Linux distributions would include an /sbin/efivars command exposing this API to every shell script running as root... So nothing would be gained. For safeguards against accidental damage, on the other hand, in completely in favour.
- JulianMorrison 11y agoWhy not just turn off recognition of "rm" in the efivarfs? That is, the response to "unlink" of a file that represents a system abstraction of firmware should be something drastic only to the unlinker. SIGSEGV or something. "Go away, don't do that."
- bcg1 11y agoIts far easier to just close the ticket and tell everyone to piss off.
- dap 11y agoThat sounds like a sign that the filesystem may be the wrong abstraction for this.
- eeZi 11y agoWell there are use cases where you'd want to remove an EFI variable.
- cnvogel 11y agoThen just require the efivars to have different semantics, just have a look like unbind works for drivers. If you really want to be super cautious, add a safeguard to enable this. echo 1 >/sys/...efi.../enable_remove echo varname >/sys/...efi.../remove_var
- sjukfan 11y agoI can't understand why people argue about this. Just put some safety measures on it already. Or at least change the rm option to "--brick-my-motherboard"
- rcxdude 11y agoHonestly, I feel the issue is more rm -rf's default behaviour being to cross filesystems. This is almost always not what you want (and tends to result in deleting network drives, to give an example which has nothing to do with systemd), especially considering attempting to delete a mount point fails.
- mikeash 11y agoI think there are at least three issues here. One is efivarfs making it too easy to destroy stuff. It should probably identify problematic hardware and prohibit modifications that break that hardware. This is no fun, but hardware-specific workarounds are a fact of life for real-world OSes. One is, as you say, bad default behavior with rm. Crossing filesystems by default is pretty weird. Preventing that unless it's explicitly requested would largely fix this problem and many others too. And one is mounting efivarfs read-write by default. It's too dangerous to be that easy to modify. I don't think it's too useful to try to pin one of these down as "the issue." They're all worth fixing.
- geggam 11y agoI believe you hit the nail on the head. Many folk with experience have a different perspective than the folk writing this stuff. Ignoring their perspective dooms you to repeating their mistakes. The Unix way isnt some holy grail holy shit perfect way. Its the simplest. Simple means its simpler to unfk. Because it will get fk'd. Rendering someones hardware DOA is a really bad thing. Leaving that as a vector of attack is irresponsible at best. If Redhat leaves this in expect legal issues.
- bsder 11y ago1) systemd is the wrong place for the safety measures. rm is also the wrong place for the safety measures. 2) remounting a mounted FS is a non-trivial operation with lots of corner cases. What happens when another program is accessing that FS at the same time? It's simple--the kernel needs to be fixed. Access to EFI should require special sequences to cause writes. systemd folks aren't going to ask for it because Linus will simply piss and moan and close as WONTFIX/NOTABUG.
- CoconutPilot 11y agoUnix 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". It worked safely before, it should still be safe to do. (yes I know about --no-preserve-root)
- magila 11y ago`rm -rf /` was never safe, even if reinstalling the system. If it worked for you then you were just lucky. In the context doing a reinstall you need to specify --one-file-system, but really you should just reformat the partition, it'll likely be much faster anyways.
- krylon 11y agoOn one episode of BSD Now[1], Bryan Cantrill tells how they made 'rm -rf /' not work on Solaris. It seems like a good idea in that they managed to stay compliant to POSIX while disarming that particular foot seeking-missile. Or, in other words: I agree completely, in fifteen years I have never used 'rm -rf /', I always used mkfs to create fresh filesystem. [1] http://www.bsdnow.tv/episodes/2015_08_19-ubuntu_slaughters_kittens http://www.bsdnow.tv/episodes/2015_08_19-ubuntu_slaughters_k...
- jhkaghjkga 11y agoWhat's that supposed to be good for? It certainly doesn't remove any file contents and to get a clean state, surely reformatting would be both easier and quicker?
- bigbugbag 11y agoExperimentation, learning, having fun, curiosity, and all the thing that make for a proficient sysadmin.
- jhkaghjkga 11y agoSo cargo-cult? Doing things out of "tradition" without understanding what they are for?
- andmarios 11y agoOne 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/firmware/efi/vars/dump-*` fixed it. Some kind of protection would be nice, but the ability to see and use efi-vars as a filesystem is useful too. If we listen to security researchers too much, our computers will be no fun.
- milkey_mouse 11y agoBreaking 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 /.
- andmarios 11y agoThe 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.
- cmurf 11y agoCould be a job for SELinux. Most of the files in efivars don't ever need modifying. So SELinux could make all files unmodifiable by default, and allow modification of the few that are needed by efibootmgr.
- snuxoll 11y agoUnless you set SELinux to run in strict mode root still has access to delete everything.
- bsder 11y agoThis isn't a systemd problem. It's a kernel problem. Allowing accidental access to a resource capable of doing permanent damage is dumb. Even embedded processors generally have an "unlock/lock" sequence when you want to write to their flash memory. The fact that the kernel doesn't require you to write a "magic number" somewhere to gain access is foolhardy.
- Aloha 11y agoSo, the short read here is, one (arguably poorly thought out) complex system interacts with another (again, arguably poorly thought out) complex system in unthought about ways... Why is anyone surprised? I'm no fan of systemd or Poettering, but this behavior is consistent for unix, root can do anything, including break peripherals or hardware thru poorly advised actions - why is this a big to do?
- bigbugbag 11y agoBecause this is a violation of principle of least astonishment[1], as a sysadmin when I hose my system using rm I expect to be able to repair or recover without having to replace the motherboard. see also: https://bbs.archlinux.org/viewtopic.php?id=207549 https://bbs.archlinux.org/viewtopic.php?id=207549 https://bbs.archlinux.org/viewtopic.php?id=208102 https://bbs.archlinux.org/viewtopic.php?id=208102 [1]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
- JdeBP 11y agoSee also https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449 .