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

11–20 of 32 posts

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

#11

Post by userbinator »

mschuster91 wrote: post #8
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.

> 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?)

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

#12

Post by userbinator »

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.

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

#13

Post by opless »

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…

According to this[1] NIS+ Probably allows it, so there's probably a nice multi-step attack possible...

[1] https://docs.oracle.com/cd/E19620-01/805-3727/userconcept-3/...

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

#14

Post by jaxtellerSoA »

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?)

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

I am not so sure about that. I work at a smallish, place and by default my AD account has UID of 945004649. Still under the INT_MAX but not that far off. Our domain controller is running Windows 2012 R2, and nothing was changed or touched regarding UID's, everything was left at the default. We just create users and get whatever UID AD assigns.

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

#15

Post by jabl »

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 with user namespaces, unmapped users again get the overflowuid.

For more details, see https://lwn.net/Articles/695478/

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

#16

Post by jabl »

kijin wrote: post #6
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.

Was the special treatment of -1 intended by the developers, or did somebody mix up signed -1 with unsigned 65535?

In POSIX, many functions return -1 to indicate errors. So I guess the value (uid_t) -1 was reserved to avoid confusion. Also some functions (chown()) allow specifying (uid_t) -1 or (gid_) -1 to mark an omitted argument.

See https://en.wikipedia.org/wiki/User_identifier#Special_values

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

#18

Post by JdeBP »

kijin wrote: post #6
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.

Was the special treatment of -1 intended by the developers, or did somebody mix up signed -1 with unsigned 65535?

See https://superuser.com/a/706578/38062 .

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

#19

Post by JdeBP »

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 assertion from failing. The worry is that some other assertion might trigger in the agent, or be introduced, that causes it to fail open in some other way. It should fail closed.

* https://gitlab.freedesktop.org/polkit/polkit/merge_requests/...

We have been down this road before with assertions.

* https://news.ycombinator.com/item?id=12655048

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

#20

Post by Vogtinator »

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…

> 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.

Post reply on HN