Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

gitlab.freedesktop.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#21

Post by JdeBP »

Vogtinator wrote: post #20
JdeBP wrote: post #19

Earlier quoted context omitted.

This is not an overflow problem. PolicyKit is deciding to exclude negative numbers from the allowable range of user IDs, causing pkttyagent to abend with an assertion failure, and then the authorization mechanism fails open . The proposed patch from the systemd developers, somewhat worryingly, apparently does not address the failing open. It simply stops PolicyKit from excluding negative numbers as UIDs, and thus the…

> causing pkttyagent to abend with an assertion failure, and then the authorization mechanism fails open Wrong. pkttyagent is just a frontend, it does not do any authorization itself. That's up to polkitd.

I didn't say that pkttyagent was the authorization mechanism. I said that the authorization mechanism fails open after pkttyagent abends. M. Poettering looked at it with a Desktop Bus monitor to inspect the transaction.

* https://github.com/systemd/systemd/issues/11026#issuecomment...

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#22

Post by gerdesj »

userbinator wrote: post #12
zaarn wrote: post #10

It should be noted that with a UID larger than INT_MAX a lot of things will start to break, ext4 for example only supports 32bit UIDs, so you won't be able to chown any files as this UID (atleast my own experimentation seems to find this. NFSv4 allows it if you enable squashing/mapping of user ids). Lots of other tools will likely break in similar and unpredictable ways if your UID becomes that high. Likely those way…

ext4 for example only supports 32bit UIDs Unsigned or signed? That seems to be the critical difference here.

I'm no C programmer but these looks like hints:

https://github.com/torvalds/linux/blob/master/fs/ext4/ext4.h...

https://github.com/torvalds/linux/blob/master/fs/ext4/ext4.h...

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#23

Post by dustfinger »

JdeBP wrote: post #19
jstimpfle wrote: post #17

Why don't we have hardware overflow traps? Most numbers should never overflow. We would need just 1 additional bit for arithmetic instructions to indicate that overflows are fine in some cases.

This is not an overflow problem. PolicyKit is deciding to exclude negative numbers from the allowable range of user IDs, causing pkttyagent to abend with an assertion failure, and then the authorization mechanism fails open . The proposed patch from the systemd developers, somewhat worryingly, apparently does not address the failing open. It simply stops PolicyKit from excluding negative numbers as UIDs, and thus the…

Yah, the title is technically not accurate since 2*(INT_MAX -1) overflows, is not negative and cannot run arbitrary systemctl commands (I have not tested though). The title would have been clear if it had read:

> unprivileged users with negative UID can successfully execute any systemctl command

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#24

Post by LinuxBender »

Has anyone found a clean way to remove polkit once installed without breaking systemd? On Redhat at least, you have to kickstart the machine without anything that pulls it in. It can't be "disabled" without breaking things and udev will trigger it regardless of the unit file state.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#25

Post by dustfinger »

dustfinger wrote: post #23
JdeBP wrote: post #19

Earlier quoted context omitted.

This is not an overflow problem. PolicyKit is deciding to exclude negative numbers from the allowable range of user IDs, causing pkttyagent to abend with an assertion failure, and then the authorization mechanism fails open . The proposed patch from the systemd developers, somewhat worryingly, apparently does not address the failing open. It simply stops PolicyKit from excluding negative numbers as UIDs, and thus the…

Yah, the title is technically not accurate since 2*(INT_MAX -1) overflows, is not negative and cannot run arbitrary systemctl commands (I have not tested though). The title would have been clear if it had read: > unprivileged users with negative UID can successfully execute any systemctl command

I was wrong. You can create UID greater than int_max. The problem happens in a policy kit assertion. pjmlp linked the policy kit issue #74 (thanks).

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#26

Post by pixl97 »

userbinator wrote: post #11
mschuster91 wrote: post #8

Earlier quoted context omitted.

> You'd have to be a privileged user to create such high uid user. Or use a broken / misconfigured AD/LDAP to sync uid/gid across a pool of machines.

...which implies already having high privileges. (How do users with such high UIDs come into existence?)

Active directory integration into Linux. Default numbers in the config files are very large.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#27

Post by emmelaich »

jabl wrote: post #15
emmelaich wrote: post #4

You'd have to be a privileged user to create such high uid user. And it's very unlikely to happen by accident, right? So can't get too excited about this. Bit of trivia - one some older Unixes (HP-UX) the uid -1 was special - was always unprivileged 'nobody' and was equal to 65535.

Others pointed out that nobody was (uint16_t) -2, or 65534. But, it turns out this value is, in fact, special in current day Linux as well. It's the default value of the special 'overflow' uid, can be seen/set at /proc/sys/fs/overflowuid. Apart from some legacy stuff using 16-bit uid's, today it's mostly used for two things 1) In NFS, if mapping a user fails, then it gets assigned the overflowuid. 2) In containers wi…

Very interesting, thanks.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#28

Post by LinuxBender »

LinuxBender wrote: post #24

Has anyone found a clean way to remove polkit once installed without breaking systemd? On Redhat at least, you have to kickstart the machine without anything that pulls it in. It can't be "disabled" without breaking things and udev will trigger it regardless of the unit file state.

Nobody on serverfault could find a way either. Most of my stuff is Alpine Linux (non-systemd) so not a big issue. At work, we have a lot of CentOS and I just advise folks to keep their kickstart minimal to avoid pulling in polkit.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#29

Post by LinuxBender »

userbinator wrote: post #11
mschuster91 wrote: post #8

Earlier quoted context omitted.

> You'd have to be a privileged user to create such high uid user. Or use a broken / misconfigured AD/LDAP to sync uid/gid across a pool of machines.

...which implies already having high privileges. (How do users with such high UIDs come into existence?)

This could happen anywhere. If you know that dynamically created users are in range {x} and AD/LDAP users are in range {y}, then a good sysadmin would choose a very high range for batch creations of specific types of accounts. This is fairly common practice. Modern Linux and Windows can support millions of UID's, so it is perfectly reasonable to say, "We are going to use range {y} for this project then nuke that entire range when we are done".

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#30

Post by JdeBP »

LinuxBender wrote: post #28
LinuxBender wrote: post #24

Has anyone found a clean way to remove polkit once installed without breaking systemd? On Redhat at least, you have to kickstart the machine without anything that pulls it in. It can't be "disabled" without breaking things and udev will trigger it regardless of the unit file state.

Nobody on serverfault could find a way either. Most of my stuff is Alpine Linux (non-systemd) so not a big issue. At work, we have a lot of CentOS and I just advise folks to keep their kickstart minimal to avoid pulling in polkit.

You will have the problem whether or not your system has systemd. It exists in PolicyKit on FreeBSD, for example.

    # setuidgid sint32maxp1 id
    uid=2147483648(sint32maxp1) gid=2147483648 groups=2147483648
    # setuidgid sint32maxp1 pkexec id

    (process:99600): GLib-GObject-WARNING **: value "-2147483648" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
    uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
    #
Post reply on HN