Summary: | utmp/wtmp locking allows non-privileged user to deny service | ||
---|---|---|---|
Product: | glibc | Reporter: | Davin McCall <davmac> |
Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | adhemerval.zanella, carlos, drepper.fsp, fweimer, sam |
Priority: | P2 | Flags: | fweimer:
security+
|
Version: | 2.29 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2019-05-14 00:00:00 |
Description
Davin McCall
2019-04-27 04:52:28 UTC
This issue seems to exist on Solaris and AIX as well, although they uses a different path (/var/run/utmpx for Solaris and /etc/utmp). As with glibc-based system, its permission is similar that it allows users to read-lock it: Solaris: $ ls -l /var/run/utmpx -rw-r--r-- 1 root bin 7440 May 14 14:56 /var/run/utmpx AIX: $ ls -l /etc/utmp -rw-r--r-- 1 root system 38232 May 14 08:39 /etc/utmp The same issue also prevents further login on the system, as sshd for instance. I think a better alternative would just to make the utmp file no accessible to user as default with the side effect of making utmp{x} interfaces return EPERM as default. I am not sure how it would play on its usage in login process, but I also don't think using a different lock file while still using default permission for /var/run/utmp would be an improvement here. The privileged process still need to have non-blocked access to utmp regardless and I think adding a timeout to abort in such cases is also not an option (besides it is not defined in the standard, it also not expected such functions fail in this scenario). Another possibility is to route utmp{x} interfaces to a privileged process. Not sure which would be the best option, thoughts? (In reply to Adhemerval Zanella from comment #1) > I think a better alternative would just to make the utmp file no accessible > to user as default with the side effect of making utmp{x} interfaces return > EPERM as default. I am not sure how it would play on its usage in login > process, but I also don't think using a different lock file while still > using default permission for /var/run/utmp would be an improvement here. > The privileged process still need to have non-blocked access to utmp > regardless and I think adding a timeout to abort in such cases is also not > an option (besides it is not defined in the standard, it also not expected > such functions fail in this scenario). Another possibility is to route > utmp{x} interfaces to a privileged process. > > Not sure which would be the best option, thoughts? Privileged processes can be expected to coordinate access and complete writes and release locks in a timely fashion. So the writers can block other writers or readers. Unprivileged readers cannot be trusted to complete reads or release locks in a timely fashion, and should have no impact on the privileged writers. The readers cannot block other writers, but could block other readers (if required). It seems like we should be able to implement this with the Linux filesystem primivites, but I haven't done a deep analysis of this issue. This is a security issue, and Florian has added security+ flag, but it's one that has existed for a long time. |