Security concerns on the Windows DBUS port

[Fan Wu]

Hi Havoc,

all truthful authentication relies on the help of the OS, be it
credentials passed in unix domain socket, or SHA1_COOKIE. For
SHA1_COOKIE, it relies on the fact that the OS protects the access of
an user's home directory by other non-root users. But the problem with
SHA1_COOKIE is that a process' user account might not have a home
directory, or the home directory is not private, like the nobody in
Unix and LocalSystem in windows. In these cases you might not be able
to use SHA1_COOKIE at all.

Cheers,
Fan

On 4/7/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> Fan Wu wrote:
> > I think the problem with windows named pipe is you can't do poll on
> > it. If so the problem can probably be solved by adding a wrapper
> > around WaitforMultipleObjects().
>
> I do agree that it would be ideal to avoid tcp, e.g. see my follow-up to
> the mail Ralf linked to in the archives.
>
> > The auto-launch support is not enough to secure/authenticate the TCP
> > connection. The fundamental issue is you can't trust the information
> > "as told" by the peer. You can only trust the info as told by the OS,
> > like the credentials passed in Unix Domain socket.
>
> It is not, however, necessary to have peer credentials; dbus has an
> extensible system for auth mechanisms. So any authentication mechanism
> you care to come up with could be used. For example, on UNIX we can use
> TCP also, but we use SHA1_COOKIE to authenticate instead of asking the
> OS for the socket credentials.
>
> Simply trusting the identity the remote peer claims to have, of course,
> is a terrible authentication mechanism. Hopefully the windows port is
> not doing that - are you sure it isn't using the SHA1_COOKIE mechanism?
>
> Havoc
>