Re: (forw) [DNG] Linux system can be brought down by sending SIGILL to Systemd

What happened with the idea that if you are running as root you can 
break the system?  If you don't want it broken, don't do stupid shit.

On 5/24/19 2:04 PM, Rick Moen wrote:
> You, too, can have an init with a built-in handler for the ILL signal.  ;->
> 
> ----- Forwarded message from Martin Steigerwald <[email protected]> -----
> 
> Date: Fri, 24 May 2019 22:04:34 +0200
> From: Martin Steigerwald <[email protected]>
> To: DNG <[email protected]>
> Subject: [DNG] Linux system can be brought down by sending SIGILL to Systemd
> 
> Hi!
> 
> Today in a Linux training a participant attempted to bring down Debian
> workstation with Systemd by sending signals to PID 1 as I invited them
> to try to bring down PID 1 while thinking for myself that this would not
> be possible from my past experiences about trying to bring down PID 1 –
> init – myself.
> 
> While sending SIGKILL to Systemd did not have any effect, sending SIGILL
> – illegal instruction – to it brought the machine to an halt. I
> reproduced it with
> 
> while true; do kill -ILL 1 ; echo -n "." ;  sleep 0.5 ; done
> 
> on my training workstation (Debian 9.9 with Systemd 232 and 4.9.0-9
> Debian Kernel with MDS mitigation).
> 
> The mouse pointer froze and the machine did not even respond to ping
> anymore! According to participants about 4 to 5 times sending the signal
> would be enough to bring down a workstation with Systemd as PID 1.
> 
> Despite all the bugs and issues I have seen or read about with Systemd I
> was very surprised about that result.
> 
> Curiously I attempted the same with the Debian on my laptop that I
> switched to SysVInit and elogind. As the elogind stuff mostly works I
> think I will switch it to Devuan once I come around to it.
> 
> I am able to run
> 
> while true; do kill -ILL 1 ; echo -n "." ; done
> 
> against SysVinit's "init" process without any issue for minutes (Debian
> Sid with sysvinit 2.93-8 and self-compiled 5.1.2 kernel, also with MDS
> mitigation). It is even running while I write this mail normally now.
> 
> Also the participants found in the manpage kill(2):
> 
> NOTES
>         The  only  signals  that  can be sent to process ID 1, the init
>         process, are those for which init has explicitly installed sig‐
>         nal handlers.  This is done to assure the system is not brought
>         down accidentally.
> 
> So if that is actually true, then it appears that Systemd initiates a
> signal handler for SIGILL for whatever reason.
> 
> I pondered about writing a bug report to Systemd developers, but
> honestly from my past experiences with upstream feedback about bug
> reports regarding Systemd I then decided not to bother about it. I am
> not willing to take in and deal with any more "this is by design, go
> away" or "this works as intended, go away" kind of responses. I am not
> interested in Systemd to a larger extent than teaching participants of
> my training what they need to know about it, when they have to deal with
> it due to distribution choices made at their employer. And yes, I also
> have a slide that summarizes critique about it, complete with links, so
> they can make up their own opinion. And no, for me it is not black and
> white, but my own decision is to go without Systemd.
> 
> This is another reason for me to start to provide Devuan VMs in the
> Proxmox VE environment I use to provide VMs of various distributions to
> the participants of my trainings. So participants can have a look at it
> and do exercises with it if they like. I already started to incorporate
> information about Devuan in some of my slides.
> 
> I share it here not to invite another bashing about Systemd, we really
> do not need to go there, but instead can focus on strengthening the
> alternatives. But I share it here to provide another reason to use a
> Systemd-free distribution like Devuan. I also share it as an example of
> the robustness of the SysVInit init process!
> 
> Thanks,
> 

-- 
Michael Eager    [email protected]
1960 Park Blvd., Palo Alto, CA 94306

_______________________________________________
svlug mailing list
[email protected]
http://lists.svlug.org/lists/listinfo/svlug