Re: [DNG] Systemd at work: rm -rf EFI

[fsmithred]

On 02/02/2016 08:05 AM, Simon Hobson wrote:
> Exposing my ignorance here, what would need to write to the EFI stuff ? That 
> article quotes someone as saying mounting it read-only would break some 
> userspace stuff - so what would it break and why does it need to write there ?
> Not having actually dealt with EFI other than as a user, I don't recall stuff 
> having to write to BIOS settings !
> 

I'm not familiar with EFI, either, but these were mentioned as needing to
write to the EFI partition:
  grub
  efibootmgr
  systemctl


Here's Poettering's last post on the github page -
https://github.com/systemd/systemd/issues/2402

"To make this very clear: we actually write to the EFI fs in systemd.
Specifically, when you issue "systemctl reboot --firmware" we'll set the
appropriate EFI variable, to ask for booting into the EFI firmware setup.
And because we need it writable we'll mount it writable for that."

Since I don't know what he's talking about, I checked the systemctl man
page, and here's what it says about the "firmware" argument to the reboot
command:

"If the optional argument arg is given, it will be passed as the
optional argument to the reboot(2) system call. The value is architecture
and firmware specific. As an example, "recovery" might be used to trigger
system recovery, and "fota" might be used to trigger a “firmware over the
air” update."

At least the paragraph above that does give a warning not to run
'systemctl reboot --force --force', which I suppose exists in case you
can't reach the power cord and really want to pull it.

I haven't seen anything mentioned that would require writing to the EFI
under ordinary circumstances.

fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd at work: rm -rf EFI

[Massimo Coppola]

Hi all,

an occasional rant from you humble almost-lurker.


From: Rainer Weikusat 



In all seriousness, what is the guy supposed to do if some
less-than-informed person accidentally deletes something he'd better


Let's not lose the point: while stupidly issuing rm -rf / was possibly 
intentional (and thus maybe not so stupid, after all) it is quite possible for 
some stranded script incorrectly called with root privileges to heavily damage 
mounted filesystem (e.g.  like a buggy Valve update script, mentioned in recent 
messages in various mailing lists, that was trashing / ).


Mistakes (bugs, intrusion attempts) happen all the time despite all means of 
prevention that we put in the system. However, the fact that a mechanisms can be 
abused is not a valid objection to bad engineering practices.


1) Let's forget for a second that some UEFI implementation is broken.

Why on earth a does a system need to have UEFI variables mounted read-write all 
of the time? It exposes those variables to higher risks of corruption.
(You don't keep a root shell with fdisk permanently open in a terminal 24/7, 
even if it would ask confirmation before rewriting the partition table, and stil 
that would not brick the machine).


Simply put, you don't keep the capability for a dangerous mechanims to change 
the system status for longer than it is needed. (Unix) security is built upon 
dropping privileges, partitioning capabilities and avoiding the root user as 
much as possible. This is standard SW design practice for a number of reasons 
that I won't even try to list. You don't keep the gas tank open just because you 
don't go around smoking, so to say...


2) Let's face that UEFI is broken on some machines, the implementation does not 
follow the standard hence deleting vars can wreak havoc when it should not.


Well, most of the HW designs have quirks that need workarounds to cope with. 
Since HW is dealt with by the kernel, the workarounds are within kernel drivers.
This particular quirk is in the firmware of the boot system, which the kernel, 
the boot loader AND some user space utilities interact with (that's a loss of 
modularity that has been already mentioned). Hence :

( if the workaround  is of reasonable complexity, must be there in those places)
 OR
( the support for that hardware/firmware has to explicitly be dropped, e.g. 
system should not even try to go and start the init process on those machines)


Surprise! Poettering is not doing either choice. He doesn't want to play safe 
with marginal hardware and firmware (I omit further polemics here...).


What happens here IMHO is that having the UEFI variables permanently writable is 
some design decision of systemd with uspoken reasons (if not simply plain 
arrogance to not reconsider one's own design choices and mistakes) and as a 
consequence some unspecified portion of the HW is at (small but increased) risk 
to be bricked if systemd is allowed to touch it.


We could ask for no better proof of the need to allow init choice, and reason 
for Devuan to exist. Of course, we cannot expect that this is ackowledged by 
those who don't want to see (further polemics removed...)


Best Regards

Massimo

--
^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^
massimo.copp...@isti.cnr.it  copp...@di.unipi.it www.di.unipi.it/~coppola
Massimo Coppola  -  Tel: +39 (050) 3152992  -  CNR mobile +39 348 3962622
CNR/ISTI "A.Faedo", via G. Moruzzi 1 - 56124 Pisa, ItalyRoom C33
-   -   -   -   -   -   -   -   -   -
Eternity is a mere moment, just long enough for a joke.(H. Hesse)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd at work: rm -rf EFI

[Simon Hobson]

Jaromil  wrote:

> meanwhile, on the background, the usual bullying goes on among the
> systemd hooligans, sarcastically liquidating the concern with some
> cynical remarks, as if it would be a deserved punition for users
> caught into a bricked laptop rather than an erased filesystem:
> 
> http://www.phoronix.com/scan.php?page=news_item=UEFI-rm-root-directory

Exposing my ignorance here, what would need to write to the EFI stuff ? That 
article quotes someone as saying mounting it read-only would break some 
userspace stuff - so what would it break and why does it need to write there ?
Not having actually dealt with EFI other than as a user, I don't recall stuff 
having to write to BIOS settings !

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Systemd at work: rm -rf EFI

[Wim]

Hi all,

It seems you can delete EFI vars if you're not careful. Someone found that
executing "rm -rf --no-preserve-root /" also deleted EFI vars, turning his MSI
Notebook into a brick.

It also seems mounting these is hardcoded into systemd:

https://bbs.archlinux.org/viewtopic.php?id=207549

efibootmgr needs to write to EFI vars, it seems. Here's Poettering's answer:

https://github.com/systemd/systemd/issues/2402

Well, you've probably guessed the answer - Won't fix.


Cheers,


Wim
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd at work: rm -rf EFI

[Clarke Sideroad]

On 02/01/2016 08:59 PM, Clarke Sideroad wrote:
> On 02/01/2016 06:12 PM, Wim wrote:
>> Hi all,
>>
>> It seems you can delete EFI vars if you're not careful. Someone found
>> that executing "rm -rf --no-preserve-root /" also deleted EFI vars,
>> turning his MSI Notebook into a brick. 
>>
>> It also seems mounting these is hardcoded into systemd:
>>
>> https://bbs.archlinux.org/viewtopic.php?id=207549
>>
>> efibootmgr needs to write to EFI vars, it seems. Here's Poettering's answer:
>>
>> https://github.com/systemd/systemd/issues/2402
>>
>> Well, you've probably guessed the answer - Won't fix.
>>
> 
> The guy is unbelievable, but as you point out predictable.
> There  is a big difference between hosing a operating system install and
> bricking a piece of hardware.
> 
> Lots of hardware has bugs that need a work around and stuff like ROMs
> that should only be RW if required. Ignoring it, not even stating a
> logical position and closing the topic just shows the quality of the man
> and his products.
> 
> Looking around he seems to have a lot of apologist on his side that
> really don't have a grasp of the situation.
> 
> One wonders if it is confined only to the one piece of hardware or if
> there are others that may share the code, looks like a potential exploit
> to me.
> 
> Some of you can just be glad that there is no room on most embedded
> systems for the systemd shenanigans. (-;
> 
>

I just received this link in an email:
http://blog.virustotal.com/2016/01/putting-spotlight-on-firmware-malware_27.html

As usual I may be over reacting, but it may add a bit of perspective to
the problem of leaving the backdoor open with read write permissions.

Clarke



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd at work: rm -rf EFI

[Clarke Sideroad]

On 02/01/2016 06:12 PM, Wim wrote:
> Hi all,
> 
> It seems you can delete EFI vars if you're not careful. Someone found
> that executing "rm -rf --no-preserve-root /" also deleted EFI vars,
> turning his MSI Notebook into a brick. 
> 
> It also seems mounting these is hardcoded into systemd:
> 
> https://bbs.archlinux.org/viewtopic.php?id=207549
> 
> efibootmgr needs to write to EFI vars, it seems. Here's Poettering's answer:
> 
> https://github.com/systemd/systemd/issues/2402
> 
> Well, you've probably guessed the answer - Won't fix.
> 

The guy is unbelievable, but as you point out predictable.
There  is a big difference between hosing a operating system install and
bricking a piece of hardware.

Lots of hardware has bugs that need a work around and stuff like ROMs
that should only be RW if required. Ignoring it, not even stating a
logical position and closing the topic just shows the quality of the man
and his products.

Looking around he seems to have a lot of apologist on his side that
really don't have a grasp of the situation.

One wonders if it is confined only to the one piece of hardware or if
there are others that may share the code, looks like a potential exploit
to me.

Some of you can just be glad that there is no room on most embedded
systems for the systemd shenanigans. (-;


Clarke

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng