Luckily, this one takes a bit more ingenuity on behalf of the attacker.
If you can manage to make someone create a user account for you, and assign you with a UID greater than two billion and peanuts (in short, INT_MAX), it's really easy to gain root privileges, because PolicyKit has a flaw in evaluating UIDs.
Let's see how this would work normally:
uid=2015(someuser) gid=2015(someuser) groups=2015(someuser) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
someuser@host$ systemd-run -t /bin/bash Failed to start transient service unit: Interactive authentication required.
This is systemd delegating a transient unit start request to PolicyKit, which says, "Nope. You need to authenticate as superuser before you can do the above."
Let's consider this example - a user named "foo" was created, and they have somehow managed to make their user ID be above two billion and peanuts. Say, three billion. (With enormous multi-tenant environments, that is not such an impossibility, to be honest.)
Let's repeat the above.
foo@host$ id uid=3000000000(foo) gid=1001(foo) groups=1001(foo) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 foo@host$ systemd-run -t bash Running as unit run-16691.service. Press ^] three times within 1s to disconnect TTY. root@host#
Again, SELinux to the rescue. If we make local users confined by default, this problem doesn't occur:
root@host# semanage login -l | grep foo foo staff_u s0 * root@host# ssh foo@localhost ... foo@host$ id -Z staff_u:staff_r:staff_t:s0 foo@host$ systemd-run -t /bin/bash Failed to start transient service unit: Access denied
Even with sysadm_u (which can use sudo and su, but needs special permissions to log in using ssh), the problem is aleviated:
root@host# semanage login -l | grep foo foo sysadm_u s0 * root@host# getsebool -a | grep ^ssh_sysadm ssh_sysadm_login --> on root@host# ssh foo@localhost ... foo@host$ systemd-run -t /bin/bash Failed to start transient service unit: Access denied
So here we have it - yet another proof how SELinux keeps your system humming much more securely on a daily basis. Users that need to administer the box can do that using sudo, and in they daily work, they are being protected from malicious use-cases by our good old watchdog.
Super helpful Grega, thanks for sharing that neat stuff.