Date: Thu, 29 Aug 2013 00:13:04 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Andriy Gapon <avg@FreeBSD.org> Cc: Greg Rivers <gcr+kde-freebsd@tharned.org>, kde@FreeBSD.org, freebsd-gnome@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-security@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: [kde-freebsd] virtualbox file dialog problem Message-ID: <20130828221303.GA53931@stack.nl> In-Reply-To: <521DE891.9070107@FreeBSD.org> References: <51E6B030.1080009@FreeBSD.org> <alpine.BSF.2.00.1307171910260.2397@badger.tharned.org> <51E793DB.2020607@FreeBSD.org> <521DE891.9070107@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@. > >> 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@. 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@. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130828221303.GA53931>