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

[Krzysztof Konopko]

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

> On 26/02/13 22:15, Krzysztof Konopko wrote:
> >     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).
>
> getpw*() and getgrouplist() are the only portable interface for this:
> /proc is Linux-specific.
>

Oh yes, this would be Linux-specific.


>
> If you wanted to extend the D-Bus policy language to support
>
>     <policy user="#0">...</policy>
>     <policy group="#42">...</policy>
>
> which didn't bother with a getpwnam() or getpwuid() and just did simple
> integer matching, that would be fine. (If you do: bug report, please.)
>

I thought it's already supported but personally I don't think it's a good
idea to use it.  To me policies should be based on "static" (well defined)
users and groups that exist on the system when dbus-daemon starts and that
can be referred by human-readable names.  Otherwise IMO it leads to sloppy
policies.

OTH I think it's fine (to some degree) if a process joins a group
"dynamically" or runs with a "dynamically" assigned UID so that policies
can be leveraged to the full extent.  The idea here is inspired by the
aforementioned Android where a newly installed application gets a unique
UID assigned and becomes a member of groups required for its normal
operation.  So one gets nice privilege separation but it becomes tricky if
anything like /etc/{passwd,group} has to be modified to achieve this.  My
approach was to separate these concerns in D-Bus by detaching from standard
libc getpw*() approach wherever possible.


>
> Similarly, I wouldn't object to a patchset which tried to obtain peer
> processes' groups via /proc on Linux, falling back to mapping the uid to
> a username then calling getgrouplist() for that username on other Unix
> platforms - but this would need to be checked for regressions on at
> least one non-/proc Unix platform, and I suspect the code structure may
> make this harder than it looks at first glance. That would resolve
> <https://bugs.freedesktop.org/show_bug.cgi?id=9328> if implemented.
>

I'm keen to make such an attempt.  With small patches and well understood
steps I think it's plausible.  It won't be a rapid activity though due to
limited amount of my spare time.  Looking forward though to get on with it.


>
>     S
>


Cheers,
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/20130227/c87f92bb/attachment-0001.html>