Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' • Hacker News Board

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

#151

Post by SEJeff » Sat, Jan 30, 2016, 5:16 PM UTC

Ao7bei3s wrote: post #148

SEJeff wrote: post #144

Earlier quoted context omitted.

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.

Actually even if you do rm -f, the -i will still be added if it is an alias. Better is to use the bash builtin "type":

type rm is better than which rm, but it depends on what distro you're using. Some distros (Just checked on RHEL7) will fancify which as well ie:

$ type which which is aliased to `alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

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

#152

Post by Ao7bei3s » Sat, Jan 30, 2016, 5:28 PM UTC

SEJeff wrote: post #151

Ao7bei3s wrote: post #148

Earlier quoted context omitted.

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.

Actually even if you do rm -f, the -i will still be added if it is an alias. Better is to use the bash builtin "type": type rm is better than which rm, but it depends on what distro you're using. Some distros (Just checked on RHEL7) will fancify which as well ie: $ type which which is aliased to `alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

> Actually even if you do rm -f, the -i will still be added if it is an alias.

Yes, I know, but rm ignores -i if -f is given.

  [root@example ~]# touch blah
  [root@example ~]# rm -i -f blah
  [root@example ~]#

And hence:

  [root@example ~]# which rm
  alias rm='rm -i'
  	/usr/bin/rm
  [root@example ~]# touch blah
  [root@example ~]# rm -f blah
  [root@example ~]#

@type: yes, you're right, thanks for the reminder.

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

#153

Post by evacchi » Sat, Jan 30, 2016, 5:50 PM UTC

uxcn wrote: post #150

threatofrain wrote: post #131

Earlier quoted context omitted.

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.

OS X had been UNIX certified, at some point, though. Don't know if that is still true

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

#154

Post by alexandrerond » Sat, Jan 30, 2016, 5:51 PM UTC

simoncion wrote: post #34

alexandrerond wrote: post #23

How long before someone realises that grub could also be made part of systemd... cringes

> How long before someone realises that grub could also be made part of systemd... https://wiki.archlinux.org/index.php/Systemd-boot

This is why I didn't even want to google it... ignorance is bliss. Thank you, i guess...

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

#155

Post by Sanddancer » Sat, Jan 30, 2016, 5:55 PM UTC

snuxoll wrote: post #99

Sanddancer wrote: post #85

Earlier quoted context omitted.

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…

I agree with you, but then we delve into the fun of needing to implement a syscall for this or a something in sysfs that limits the damage that can be done. I suppose it's better than the current efivars filesystem, but neither is a wonderful solution when we have to limit access to the hardware that could potentially do useful things (without patching the kernel, of course).

It's useful, yes, but because of the buggy implementations out there, the risk in bricking, wanton removal of important variables, etc, is just too great. If anything, it should be a device node or the like. /dev/efi makes a lot more sense given its structure and purpose than trying to abstract it into looking kinda sorta like a filesystem.

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

#156

Post by snuxoll » Sat, Jan 30, 2016, 5:59 PM UTC

mikeash wrote: post #141

snuxoll wrote: post #102

Earlier quoted context omitted.

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.

Maybe if there was some awful Windows virus that nuked boards with bad implementations they would fix their crap.

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

#157

Post by snuxoll » Sat, Jan 30, 2016, 6:09 PM UTC

Sanddancer wrote: post #155

snuxoll wrote: post #99

Earlier quoted context omitted.

I agree with you, but then we delve into the fun of needing to implement a syscall for this or a something in sysfs that limits the damage that can be done. I suppose it's better than the current efivars filesystem, but neither is a wonderful solution when we have to limit access to the hardware that could potentially do useful things (without patching the kernel, of course).

It's useful, yes, but because of the buggy implementations out there, the risk in bricking, wanton removal of important variables, etc, is just too great. If anything, it should be a device node or the like. /dev/efi makes a lot more sense given its structure and purpose than trying to abstract it into looking kinda sorta like a filesystem.

My big problem at the end of the day is while we can help prevent users from killing their own boards - we still NEED to be holding these firmware vendors accountable. No matter what abstraction is presented to user space once someone has root on my system they could potentially destroy my hardware.

Maybe one there is some nasty Windows Virus out there that fries boards by deleting EFI variables these stupid vendors will get their shit in order.

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

#158

Post by snuxoll » Sat, Jan 30, 2016, 6:32 PM UTC

simoncion wrote: post #94

jerf wrote: post #45

Earlier quoted context omitted.

(Honest question, I lack hardware to check this on myself:) What do non-systemd systems do about this?

If I had a system that I booted in UEFI mode, I could tell you, but all of my hardware (even the ones running UEFI) boot OSs in BIOS mode. 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 mount…

A traditional BIOS or UEFI running in CSM requires an MBR formatted disk since the bootloader must be started from the first 512 bytes on disk. I have to boot ESXi on my ProLiant ML10 off a flash drive because my 3TB disk would become a 2TB disk otherwise.

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

#159

Post by snuxoll » Sat, Jan 30, 2016, 6:52 PM UTC

cmurf wrote: post #66

Could 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.

Unless you set SELinux to run in strict mode root still has access to delete everything.

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

#160

Post by digi_owl » Sat, Jan 30, 2016, 7:06 PM UTC

krylon wrote: post #143

pdkl95 wrote: post #135

Earlier quoted context omitted.

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

Frankly i feel that way to many sub-projects within systemd is at this point "i can rewrite this faster than get patches past the maintainers". Often with the "hilarious" outcome that problem that was solved a decade ago crops up again in the new implementation within systemd.