Created attachment 358163 [details] Patch switching dbus to libcap-ng Description of problem: dbus is linking against libcap currently. I am in the process of add code to apps to drop capabilities wherever possible. It turns out that they link against libdbus which causes them to link against both libcap and libcap-ng. The best solution is to just convert dbus over to libcap-ng. Doing this deletes a bunch of lines of code from dbus since its all functionality that libcap-ng natively handles. You would have to change the BuildRequires to libcap-ng-devel besides applying this patch. Version-Release number of selected component (if applicable): 1.2.16-4
Will this fix https://bugzilla.redhat.com/show_bug.cgi?id=510868 too?
Also what is the status of libcap-ng in "Linux" (by this I mean besides Fedora, basically Ubuntu, Moblin, OpenSUSE).
wrt comment #1, this doesn't specifically fix that bug, but this is probably the 10th time the problem has reappeared. Libcap-ng will allow for an easy fix for that problem though. It allows doing something like this: if (capng_have_capability(CAPNG_EFFECTIVE, CAP_AUDIT_WRITE)) send_avc(); This is more correct that checking to see if you are root. As for comment #2, I am not tracking other distros. But I know that its being put into Debian. The audit 2.0 package uses it, so the other major distros will pull it in sooner or later.
On second thought, it might help fix the problem in comment #1. The code I patched out might not have been correct. The function in libcap-ng to change uid while retaining capabilities is well tested and known to work. So, maybe it does help it. FWIW, my rawhide laptop is running with a patched dbus and seems to work fine.
I can take a shot at it. Actually, solving the problem is far easier than passing flags. If you have CAP_AUDIT_WRITE, you can send just fine. No matter what uid you have. CAP_AUDIT_WRITE goes back to RHEL4.2 time (2.6.12 approximately), so it should be available on all platforms we care about. I'll attach an improved patch later.
Created attachment 358262 [details] Patch to drop capabilities This patch adds a check for CAP_AUDIT_WRITE before sending the audit event.
Hi...any objections to the patch? I would prefer to make this switch sooner than later so that there is some runtime on it before beta freeze. Thanks.
Any objections to this patch? We are almost out of time for beta freeze. We really need to get this applied so we can see if there are any issues. The patch should be good for dbus since it lowers the number of lines of code needed to change uid and keep capabilities.
Colin, can you take a look at this ?
Just for the record, libcap-ng should work correctly on all 2.6 kernels. The only issue is that auditing is not on all kernels. So, libaudit is the limiting factor. I've done some testing. I think the patch needs to be changed slightly. It turns out that when the bounding set is cleared, some child process that dbus starts does not have the permissions it needs. The effect is that when you get to the gdm login prompt, there are no names to click on for login. I will attach an updated patch. Also, it would be worthwhile to try adding %{?_smp_mflags} to make in the %build section so that multi-core systems can build dbus faster. It works on my quad core like this.
Created attachment 363558 [details] Updated patch dropping capabilities This patch does not clear the bounding set. Please apply this one instead.
I've put the patch in dbus-1.2.16-8.fc12 and asked for it to be tagged.
I've upgraded today my rawhide system - and got this version - and I must say it was non-trival task to downgrade back to version 1.2.16-6. I think version 1.2.16-8.fc12 is very dangerous - there are not many things that works today without dbus....
So...why did you downgrade? What is dangerous?
Ok - got some time to lurk around the problem. I'm not using rawhide's kernel for various reasons. Thus dbus-daemon --system gives this: munmap(0x7f7063033000, 4096) = 0 open("/var/run/messagebus.pid", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4 fcntl(4, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7063033000 lseek(4, 0, SEEK_CUR) = 0 write(4, "2465\n"..., 5) = 5 close(4) = 0 munmap(0x7f7063033000, 4096) = 0 syscall_294(0x80000, 0x7f706508a0a0, 0x7f706509e250, 0x7fff60b4b010, 0x1, 0x3, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80, 0x7f706508ed80) = 0x4 inotify_add_watch(4, "/etc/dbus-1/system.d", IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_DELETE) = 1 geteuid() = 0 capget(0x20080522, 0, NULL) = -1 EINVAL (Invalid argument) prctl(0x8, 0x1, 0, 0, 0) = 0 capset(0x20080522, 2465, {CAP_SETGID|CAP_SETUID|CAP_SETPCAP|0x20000000, CAP_SETGID|CAP_SETUID|CAP_SETPCAP|0x20000000, 0}) = -1 EPERM (Operation not permitted) close(3) = 0 unlink("/var/run/dbus/system_bus_socket") = 0 unlink("/var/run/messagebus.pid") = 0 write(2, "Failed to start message bus: Fail"..., 83) = 83 exit_group(1) = ? Effectively this stops dbus completely - and my whole gnome desktop gets knocked down - which is IMHO unexpectable and undesirable. See the attachment of xsession-errors file. What was even more problematic is - that Xorg was usable only thank to my old hand written Xorg file which still allowed me to use keyboard,mouse...
Created attachment 364240 [details] xsession_error with broken dbus
The strace is helpful. Which kernel are you using? Do you have selinux enabled? Do you have any avcs?
I see in your xsession, Build Operating System: 2.6.18-128.4.1.el5xen, if that is the case, you would probably need binaries built against RHEL kernel headers so that the right OS features are enabled/disabled.
I'm running vanilla kernel 2.6.32-rc3 with selinux disabled. I do not use any security policies/calculability whatever you name.... Hopefully this is still 'allowed' combination. Also I'm running 'rawhide' Xorg packages...
The eperm is caused by the setpcap capability. This is only needed if we are clearing the bounding set. I built a new libcap-ng here: http://koji.fedoraproject.org/koji/buildinfo?buildID=135936 that should work around this problem. Would this new libcap-ng build make dbus work for you?
Yes I can confirm that libcap-ng-0.6.2-3 make this new dbus package working again. good work
Thanks for checking this. I will ask for the update to be pushed.