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

[Krzysztof Konopko]

2013/2/26 Simon McVittie <simon.mcvittie at collabora.co.uk>

> 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]().
>

I was actually considering interposing original getpw*() functions in the
dbus-daemon executable (patching libc in my case would be very hard for
non-technical reasons) but I found /proc approach less invasive and less
complicated.  I still wanted some calls to getpw*() fail if the user/group
cannot be found (e. g. parsing policies) and control which calls should
lookup for credentials in /proc if PID is available.


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

Actually the system I work with has the idea of "dynamic" users inspired by
Android.  I just couldn't afford the full-blown "my own libc"
implementation approach.


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

I've been considering tidying it up and making generic enough to
potentially replace some getpw*() calls altogether as the latter ones are
just an "implementation detail".  In many cases all that D-Bus daemon cares
about is the same what the kernel cares about: numbers (UIDs/GIDs).


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

Agree, possible at least in theory.  Thankfully not possible with the
mainstream libdbus as I understand the above correctly (credentials are
checked when creating a new connection as far as I remember).


>
>     S
>

Thanks for sharing your thoughts.

Kris


> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130226/6168b7a6/attachment.html>