Bugzilla – Bug 1025175
Normal user can power off a Opensuse machine without elevated privlages using systemCTL
Last modified: 2017-02-14 22:31:57 UTC
Since the implementation of SystemD i have found that it is possible for a normal user to be able to power down a machine without elevated privileges or logging in as root. Versions of OpenSUSE effected: 13.1, 13.2, 42.1, 42.2, Tumbleweed, Arm + x86 + X86_64 Command: $ systemctl poweroff Expected result is that the poweroff command fails asking for root privlages. Actual result, machine powers off killing off any other users and services that are running. Other tested commands: $ systemctl reboot
(In reply to Patrick Finie from comment #0) > Since the implementation of SystemD i have found that it is possible for a > normal user to be able to power down a machine without elevated privileges > or logging in as root. > > Versions of OpenSUSE effected: > 13.1, 13.2, 42.1, 42.2, Tumbleweed, Arm + x86 + X86_64 > > > Command: > > $ systemctl poweroff > > > Expected result is that the poweroff command fails asking for root > privlages. > > Actual result, machine powers off killing off any other users and services > that are running. > > Other tested commands: > > $ systemctl reboot Expected results based on Debian. $ systemctl poweroff ==== AUTHENTICATING FOR org.freedesktop.login1.power-off === Authentication is required for powering off the system. Authenticating as: ,,, (MirChip9dollacomputer) Password: Failed to execute operation: Connection timed out Failed to start poweroff.target: Access denied
This is intentional for desktop class systems for users who otherwise have physical access to the machine. Case in point: Log into the machine using ssh: $ systemctl poweroff ==== AUTHENTICATING FOR org.freedesktop.login1.set-wall-message === Authentication is required to set a wall message Authenticating as: root Password: This would only be security relevant if we make guarantees to the contrary, e.g. when we say that this is not supposed to work, or offer a setting that is ineffective. Please demonstrate that this is the case.
(In reply to Andreas Stieger from comment #2) > This is intentional for desktop class systems for users who otherwise have > physical access to the machine. > > Case in point: Log into the machine using ssh: > > $ systemctl poweroff > ==== AUTHENTICATING FOR org.freedesktop.login1.set-wall-message === > Authentication is required to set a wall message > Authenticating as: root > Password: > > This would only be security relevant if we make guarantees to the contrary, > e.g. when we say that this is not supposed to work, or offer a setting that > is ineffective. Please demonstrate that this is the case. So a normal user without sudo should be able to power off a Opensuse machine? I Put this under Security because there is a SystemD category. Also having a non-root user be able to control the powerstate of a machine could be considered a breech of security. Here is a video link of this in action in a VM. I did this in a VM only because if i did it to my running machine i would lose my background processes like the recording software. https://www.youtube.com/watch?v=L6ToxAUYc9s
(In reply to Patrick Finie from comment #3) > So a normal user without sudo should be able to power off a Opensuse > machine? Yes, if logged in to a VT or the local X server. This is what you ostensibly left out. That's the whole point of differentiating these permissions via services. Everything else is just arguing what the default should be. Please read in... grep power-off /etc/polkit-default-privs.* YaST / Security and Users / Security Center and Hardening / ... e.g. setting the profile to network server will change that behaviour and ask for elevated privileges. > Also having a non-root user be able to control the powerstate of a machine > could be considered a breech of security. Not if this was actually intended. And it is intended for desktop class systems. It would only be a security issue if the stated goal was that this was not possible. See above, you are simply mistaken. > Here is a video link of this in action in a VM. I did this in a VM only > because if i did it to my running machine i would lose my background > processes like the recording software. > > https://www.youtube.com/watch?v=L6ToxAUYc9s Nice. Same rationale applies. Also if you are in a VM host you control the whole machine anyway, equivalent to physical access. Resolving as invalid: Intended behavior. Adjust permissions profiles to effect the desired polkit configuration. Feel free to re-open if you can demonstrate that contrary to the intended and configured behavior this crosses a security boundary.