[kde-freebsd] virtualbox file dialog problem
jilles at stack.nl
Wed Aug 28 22:13:20 UTC 2013
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 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.
> >>  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
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:
> 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
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.
More information about the freebsd-standards