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. 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. So, possible solutions: A. change how issetugid(2) works on FreeBSD; a comment in sys_issetugid hints that other BSDs may have different behaviors B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself after dropping the privileges C. patch dbus port to not use issetugid(2) D. something else What do you guys think? -- Andriy Gapon
on 28/08/2013 15:09 Andriy Gapon said the following:> 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. > > 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. > > So, possible solutions:[snip]> B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself > after dropping the privileges[snip] BTW, I've just found this "interesting" code in the VirtualBox sources (forgive me a full paste, but I couldn't resist): #if defined(RT_OS_DARWIN) # include <dlfcn.h> # include <sys/mman.h> # include <iprt/asm.h> # include <iprt/system.h> /** Really ugly hack to shut up a silly check in AppKit. */ static void ShutUpAppKit(void) { /* Check for Snow Leopard or higher */ char szInfo[64]; int rc = RTSystemQueryOSInfo (RTSYSOSINFO_RELEASE, szInfo, sizeof(szInfo)); if ( RT_SUCCESS (rc) && szInfo[0] == '1') /* higher than 1x.x.x */ { /* * Find issetguid() and make it always return 0 by modifying the code. */ void *addr = dlsym(RTLD_DEFAULT, "issetugid"); int rc = mprotect((void *)((uintptr_t)addr & ~(uintptr_t)0xfff), 0x2000, PROT_WRITE|PROT_READ|PROT_EXEC); if (!rc) ASMAtomicWriteU32((volatile uint32_t *)addr, 0xccc3c031); /* xor eax, eax; ret; int3 */ } } #endif /* DARWIN */ -- Andriy Gapon
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 behaviorsI 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 privilegesThis 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 elseTwo 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