Web lists-archives.com

Embarrassing security bug in systemd




Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...

Of course, my son doesn't have any special privileges, no entry in
/etc/sudoers, etc.  But then I see

    $ ls -l /sbin/reboot
    lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
    $ ls -l /bin/systemctl
    -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
    $ dpkg -S /bin/systemctl
    systemd: /bin/systemctl

The /bin/systemctl binary is not suid root, so I assume[1] it
communicates to systemd which then reboots the machine without
checking what user the request comes from.

I wonder how can such a severe bug make it into a Debian stable
distribution?  And is this just an insane default setting on Debian's
side or is it yet another instance of brain-dead systemd behavior?

Searching the man pages I couldn't find a way to fix this.  How can
that be stopped?

[1] Of course, this is not docuemented in systemctl(1) as usual with
    systemd.  Also, according to the man page, systemctl must be
    called with a "COMMAND" argument which /sbin/reboot doesn't do.
    Obviously, systemctl looks at the name it was called and somehow
    uses that as command.  The admin shall guess about this.


urs