[kde-freebsd] virtualbox file dialog problem

[Jilles Tjoelker]

On Wed, Aug 28, 2013 at 03:09:53PM +0300, Andriy Gapon wrote:
> on 18/07/2013 10:06 Andriy Gapon said the following:
> > on 18/07/2013 03:25 Greg Rivers said the following:
> >> On Wed, 17 Jul 2013, Andriy Gapon wrote:

> >>> I run virtualbox in KDE environment.  A while ago (can't say
> >>> exactly when) I started to have a problem where any file opening
> >>> dialog would fail with this message: "Cannot talk to klauncher:
> >>> Not connected to D-Bus server"
> >>>
> >>> I found that setting KDE_FORK_SLAVES=1 in environment works around
> >>> the problem.
> >>
> >> I reported this same problem in this[1] thread on freebsd-ports at .
> >> In that post I provided a link to a similar report for KDE on
> >> openSUSE that required a dbus patch to fix.

> >> I'm guessing that either the latest versions of VirtualBox have a
> >> bug in their dbus interface, or the version of dbus we have needs
> >> to be updated.

> >> [1] http://lists.freebsd.org/pipermail/freebsd-ports/2013-July/084783.html

> > I saw those OpenSUSE reports but I think that they were against the
> > much older version of dbus.

> I have done some more investigation and the problems turns out to be dbus
> related indeed.

> The problem has only a tangential relation to KDE, so I plan to drop
> kde@ from this thread.  It has a relation to what VirtualBox does, so
> I am keeping emulation at .  It is related to dbus and gnome@ is its
> maintainer(s).  It is also related to how issetugid(2) works, so I am
> including standards@, security@ and hackers at . So, please excuse me for
> such a wide distribution list, but I think that the solution should be
> negotiated among the parties involved.

> Now a description of the problem.

> 1. VirtualBox executable is installed setuid root.  Apparently, when
> it is run it does some privileged things and then drops all of the
> uids and gids (real, effective and saved) back to what they should
> have been originally. VirtualBox does not do any (re-)exec of itself
> after the above manipulations.

> 2. issetugid(2) (which is apparently a BSD extension) on FreeBSD does
> not consider the above manipulations as sufficient to mark an
> executable as untainted.  So it would return 1 for the VirtualBox
> process.

The manipulations do not guarantee that all privileged information and
descriptors are no longer in the process. Often, a process will acquire
some privileged resource and then drop to user credentials; for example,
a raw socket in ping(8). Also, calls like getpwuid() might leave
privileged information in memory.

> 3. dbus code seems to impose some limitations on communication by such
> "tainted" processes.  It has the following code:
> http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c#n4139
> For web-impaired :) the gist is that on BSD systems the code uses
> issetugid but on other systems (like Linux) it uses getresuid and
> getresgid and checks that all 3 uids are the same and all 3 gids are
> the same.

> As a result, on FreeBSD the dbus code would consider the VirtualBox
> process tainted and that impairs its communication with KDE
> components. On systems without issetugid or those that implement it
> differently, dbus would work as for a normal process and all the
> communications are OK.

> I've also verified this conclusion by forcing dbus to use the
> alternative logic on FreeBSD.

I think dbus is doing the right thing on BSD and the
getresuid/getresgid-based check on Linux is a bug. This bug was reported
on https://bugs.freedesktop.org/show_bug.cgi?id=52202 however it was
decided not to fix the bug because gnome-keyring-daemon relies on it.
The gnome-keyring-daemon obtains cap_ipc_lock privilege (capability in
Linux terms) from the filesystem and needs untrusted environment
variables to work. (Note that this also means that moving a program from
setuid root to capabilities may decrease security, since dbus and glib
no longer know to be careful.)

> So, possible solutions:

> A. change how issetugid(2) works on FreeBSD; a comment in
> sys_issetugid hints that other BSDs may have different behaviors

I think it works correctly.

By the way, issetugid(2) man page appears a bit too focused on
UIDs/GIDs. The implementation also sets the bit (and rightly so) if MAC
causes a transition on execve(2) or if jail_attach(2) is called.

> B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself
> after dropping the privileges

This would be good, but it may need invasive changes to VirtualBox that
its developers do not want to make.

> C. patch dbus port to not use issetugid(2)

This may open up security holes.

> D. something else

Two ideas.

Firstly, a hack in VirtualBox that subverts issetugid() or
_dbus_check_setuid() somehow may be appropriate. This does not require
invasive changes to VirtualBox, and if you want a secure system you do
not install VirtualBox anyway.

This subversion could be done by overwriting the code of issetugid() or
by inserting a dummy implementation of issetugid() with FBSD_1.0 version
before libc.so in the lookup order, for example.

Secondly, if setting KDE_FORK_SLAVES=1 works around the problem, perhaps
KDE should behave that way automatically if it is called from a process
with issetugid() true.

-- 
Jilles Tjoelker