CentOS - Feb 2016 - In A UEFI World, "rm -rf /" Can Brick Your System

On Mon, February 1, 2016 1:56 pm, Valeri Galtsev wrote:
>
> On Mon, February 1, 2016 1:33 pm, m.roth at 5-cent.us wrote:
>> Excerpt:
>> Running rm -rf / on any UEFI Linux distribution can potentially
>> perma-brick your system.
>
> Yes, I kind of like "rm -rf /". If my memory doesn't fail me,
long ago it
> was one of the tricky questions in sysadmin exam (not that anymore if I
> read what you, Michael, write further correctly...). Anyway, let's
imagine
> we are back then, then what
>
> rm -rf /
>
> will do you your system? How dramatic this command is?
>
> Well, it definitely will obliterate your /etc with all your settings. Then
> it will start deleting /dev, and once it deletes the block device your
> root filesystem "/" lives on, all trouble ends there. So, you
just take
> your drive, and you will be able to mount on different machine /home,
> /usr, /var and what's left of your / partition. /etc is gone, bit this
> only as dramatic as it gets (thanks for alphabetical order the command
> follows).
I just discovered that I couldn't even re-cite alphabet correctly today:
it is /bin that you loose, but /etc alphabetically goes after /dev, so
will not even loose your /etc, all you will need it to restore portion of
your /dev and the whole /bib (which you can do easily if you have
"twin"
system around...)
>
> Sorry about long spam message, everybody. I just so liked that tricky
> question from my past, I couldn't hold myself.
>
> Valeri
>
>>
>> As a public service announcement, recursively removing all of your
files
>> from / is no longer recommended. On UEFI distributions by default where
>> EFI variables are accessible via /sys, this can now mean trashing your
>> UEFI implementation.
>>
>> There is this systemd bug report requesting that UEFI variables be
>> mounted
>> as read-only by default. Lennart Poettering had initially responded and
>> simply said, "Well, there are tools that actually want to write
it. We
>> also expose /dev/sda accessible for root, even though it can be used to
>> hose your system. The ability to hose a system is certainly reason
>> enought
>> to make sure it's well protected and only writable to root. But
beyond
>> that: root can do anything really." He then closed the ticket.
>> --- end excerpt ---
>>
>>
<http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory>
>>
>> "And they closed the ticket"? That tuxedo on the cockroach is
so
>> elegent!
>>
>> Ok, *now* tell me why we shouldn't hate systemd?
>>
>>        mark
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS at centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> ++++++++++++++++++++++++++++++++++++++++
> Valeri Galtsev
> Sr System Administrator
> Department of Astronomy and Astrophysics
> Kavli Institute for Cosmological Physics
> University of Chicago
> Phone: 773-702-4247
> ++++++++++++++++++++++++++++++++++++++++
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

wait.   would deleting the inode /sys/(whatever)  actually modify UEFI 
memory?    sure, writing to those inodes could do all sorts of harm, but 
deleting the inodes in the /sys filesystem, I'm not so sure this isn't a
tempest in a teapot so to speak.





-- 
john r pierce, recycling bits in santa cruz

John R Pierce wrote:
> wait.   would deleting the inode /sys/(whatever)  actually modify UEFI
> memory?    sure, writing to those inodes could do all sorts of harm, but
> deleting the inodes in the /sys filesystem, I'm not so sure this
isn't a
> tempest in a teapot so to speak.
It's going to get /boot. And under there, it'll get /boot/EFI.

      mark

On 02/01/2016 01:48 PM, Valeri Galtsev wrote:
> I just discovered that I couldn't even re-cite alphabet correctly
today:
> it is /bin that you loose, but /etc alphabetically goes after /dev, so
> will not even loose your /etc,
I'm pretty sure none of that is correct.  Once "rm" launches, all
of the
libraries and files that it needs are memory mapped and reference 
counted, so they're going to remain available while it removes the 
entire filesystem structure.

Spin up a VM and try it out.

On 02/01/2016 01:59 PM, John R Pierce wrote:
> would deleting the inode /sys/(whatever) actually modify UEFI memory?
Yes.  That is how the UEFI management interface works.

On Mon, February 1, 2016 4:23 pm, Gordon Messmer wrote:
> On 02/01/2016 01:48 PM, Valeri Galtsev wrote:
>> I just discovered that I couldn't even re-cite alphabet correctly
today:
>> it is /bin that you loose, but /etc alphabetically goes after /dev, so
>> will not even loose your /etc,
>
> I'm pretty sure none of that is correct.  Once "rm" launches,
all of the
> libraries and files that it needs are memory mapped and reference
> counted, so they're going to remain available while it removes the
> entire filesystem structure.
All true, except for: to actually write stuff permanently to hard drive
(that is modify whatever the content of hard drive is) the system needs to
access /dev/sda1 (I call from now /dev/sda1 device which "/"
filesystem
lives on), and once /dev/sda1 is deleted there will be no further hard
drive write operations. There will be no way for system to access anything
under /, which will cause "rm" command to fail fataly. I will
kickstart
install centos 7 in a moment and will do exactly this:

cd /

rm -rf /

(the first command is to avoid even "can not get CWD", which
shouldn't
matter ;-)

So, I'll see in a moment how much I'll loose on the drive, and will it
or
will it not be sufficient to rsync /boot from "twin" box, and restore
/bin
symlink. Will get back with either "crap, indeed I was wrong", or
"yes,
even on latest CentOS 7 system it is still so". Whatever the result is,
I'll enjoy this experiment. Thanks for giving me incentive to do it!

Incidentally, let me know if there is anything I should change in my
experiment for that to give us more definite answers that just "oh, look,
I still have /etc, /home, /usr... intact on hard drive". What specifically
should I do to learn that in a course of this command /sys was never
touched? Any ideas?

Valeri


++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++