[Bug libc/24492] utmp/wtmp locking allows non-privileged user to deny service

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24492

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.