[PATCH] fill_user_info: fake user info for 'root' if it can not be found

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Feb 26 04:11:30 PST 2013


On 25/02/13 23:08, Krzysztof Konopko wrote:
> The reason for that is that the system has a
> requirement to assign UIDs and GIDs dynamically without modifying
> /etc/passwd & friends.  The other reason is that the libc implementation
> we are constrained to (certain version of uClibc) doesn't support
> alternative methods of user authentication (e. g. NSS [1]) nor D-Bus
> supports PAM authentication.

To be honest this sounds like it would be better done with a patched
libc, or if you can't do that, linking a "my_getpwent[_r]()" with
libdbus and applying the minimal patch to make it use that instead. That
would also be applicable to every other application that uses
getpwent[_r]().

(See also Android's Bionic libc, whose getpwent is hard-coded to map a
certain UID/GID range to synthesized users of the form 'app%d', if I
remember correctly.)

Rummaging in /proc for credentials is an interesting approach: if done
incorrectly it can be a time of check/time of use vulnerability, but I
think you've avoided that.

The potential vulnerability is if you delay credentials lookups until
messages are sent/received (which mainstream libdbus carefully doesn't
do, but third-party LSM integration has sometimes done), a process can
avoid the checks by becoming more privileged while keeping the same pid,
by exec()ing a setuid binary. Exploit: send a message that you shouldn't
be allowed to send, then immediately exec() a binary that *would* have
been allowed to send it. You are now racing with the dbus-daemon. If
dbus-daemon wins the race, the exploit doesn't work, but if you win the
race, by the time it asks your credentials you've been replaced by a
more privileged binary, and the message is wrongly accepted

    S


More information about the dbus mailing list