Embarrassing security bug in systemd

[Urs Thuermann <urs@isnogud.escape.de>]

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