abrt 1.0.8 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session component: dbus executable: /bin/dbus-daemon kernel: 2.6.32.9-67.fc12.x86_64 package: dbus-1:1.2.16-9.fc12 rating: 4 reason: Process /bin/dbus-daemon was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine)
Created attachment 399506 [details] File: backtrace
This one ends in avc_has_perm; any ideas offhand dan? I've gotten several of these now.
No idea. Steven?
Hmmm..note that tsid=0x0 (NULL), so dbus is calling avc_has_perm() with a NULL pointer. Should be the bus_sid since proposed_recipient=0x0. bus_sid gets initialized by bus_selinux_full_init() and cleared by bus_selinux_shutdown(). Maybe it needs to be initialized earlier?
(In reply to comment #4) > Hmmm..note that tsid=0x0 (NULL), so dbus is calling avc_has_perm() with a NULL > pointer. Should be the bus_sid since proposed_recipient=0x0. bus_sid gets > initialized by bus_selinux_full_init() and cleared by bus_selinux_shutdown(). > Maybe it needs to be initialized earlier? I don't think so - we call bus_selinux_full_init before we even run the mainloop, and bus_selinux_shutdown is only called after we exit it. My guess after tracing the code a bit more is that we're hitting one of the error paths in bus_selinux_full_init, like: if (avc_init ("avc", &mem_cb, &log_cb, &thread_cb, &lock_cb) < 0) { _dbus_warn ("Failed to start Access Vector Cache (AVC).\n"); return FALSE; } In that case (or if getcon/avc_context_to_sid failed), we'd be left with a NULL sid. I think our error handling in bus_selinux_full_init is wrong; either we need to: * Treat it as fatal * Set selinux_enabled to FALSE (And really, we need to actually log this stuff to syslog rather than printing to stderr which is /dev/null'd by default...) Stephen/Dan: Do you guys have any ideas offhand about what kind of error might be occurring at runtime here? And which of the two options for error handling would you prefer?
Note if we treat it as fatal, the rest of the OS, at least for desktop is unlikely to boot.
Or really, maybe it's this bit of code from bus/bus.c that's conceptually busted: if (!bus_selinux_full_init ()) { _dbus_warn ("SELinux initialization failed\n"); } ... continue on ...
Created attachment 399695 [details] add fatal logging function
Created attachment 399696 [details] make SELinux initialization failure fatal
Did the bug reporter get any messages in /var/log/messages? Within avc_init(), the error code paths all invoke the log_callback provided by dbus, which should log via audit if allowed or fall back to syslog otherwise. So any error there should show up in audit or syslog.
Did you mean to switch component from dbus to 0xFFFF?
Thom if you're reading this, can you open System Tools->Terminal, and run this command: su -c "grep dbus /var/log/messages > /tmp/dbus.syslog && chown -h $USER: /tmp/dbus.syslog" and attach the file /tmp/dbus.syslog here?
This should be the relevant part... Mar 7 16:12:03 <host> dbus-daemon: avc: could not determine enforcing mode Mar 7 16:12:03 <host> kernel: dbus-daemon[<pid>]: segfault at 0 ip 00007f412152b95d sp 00007fff5e5b7370 error 4 in libselinux.so.1[7f4121525000+1c000] <snip> Mar 7 16:12:33 <host> kdm: :0[<pid>]: Cannot open ConsoleKit session: Unable to open session: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had sender "(unset)" interface "org.freedesktop.DBus" member "Hello" error name "(unset)" destination "org.freedesktop.DBus") Mar 7 16:12:33 <host> kdm: :0[<pid>]: Client start failed Mar 7 16:12:33 <host> kdm: :0[<pid>]: Cannot close ConsoleKit session: Unable to close session: no session open Mar 7 16:12:34 <host> dbus-daemon: avc: could not determine enforcing mode Mar 7 16:12:34 <host> kernel: dbus-daemon[<pid>]: segfault at 0 ip 00007f8af519b95d sp 00007fff415ad720 error 4 in libselinux.so.1[7f8af5195000+1c000] <snip> Mar 7 16:12:51 <host> kdm: :0[<pid>]: Cannot open ConsoleKit session: Unable to open session: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had sender "(unset)" interface "org.freedesktop.DBus" member "Hello" error name "(unset)" destination "org.freedesktop.DBus") Mar 7 16:12:51 <host> kdm: :0[<pid>]: Client start failed Mar 7 16:12:51 <host> kdm: :0[<pid>]: Cannot close ConsoleKit session: Unable to close session: no session open Mar 8 16:12:52 <host> abrt[<pid>]: can't read /proc/<pid>/exe link abrt log has Core was generated by `/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session'. Program terminated with signal 11, Segmentation fault. #0 0x00007fcaa8cd192d in avc_lookup (ssid=0x7fcaa99c0490, tsid=0x0, tclass=<value optimized out>, requested=2, aeref=0x7fcaa95840b8, avd=0x7fff0ed8d110) at avc.c:424 424 avc.c: No such file or directory. in avc.c
Thanks Thom, so the important part here is: Mar 7 16:12:03 <host> dbus-daemon: avc: could not determine enforcing mode What does 'ls -al /selinux' print on your computer?
Created attachment 399760 [details] show strerror for security_getenforce Stephen could you take a look at this patch for libselinux?
drwxr-xr-x. 7 root root 0 2010-03-11 17:08 /selinux <snip> -rw-rw-rw-. 1 root root 0 2010-03-11 17:08 access dr-xr-xr-x. 2 root root 0 2010-03-11 17:08 avc dr-xr-xr-x. 2 root root 0 2010-03-12 10:54 booleans -rw-r--r--. 1 root root 0 2010-03-11 17:08 checkreqprot dr-xr-xr-x. 154 root root 0 2010-03-12 10:54 class --w-------. 1 root root 0 2010-03-11 17:08 commit_pending_bools -rw-rw-rw-. 1 root root 0 2010-03-11 17:08 context -rw-rw-rw-. 1 root root 0 2010-03-11 17:08 create -r--r--r--. 1 root root 0 2010-03-11 17:08 deny_unknown --w-------. 1 root root 0 2010-03-11 17:08 disable -rw-r--r--. 1 root root 0 2010-03-11 17:08 enforce dr-xr-xr-x. 2 root root 0 2010-03-11 17:08 initial_contexts -rw-------. 1 root root 0 2010-03-11 17:08 load -rw-rw-rw-. 1 root root 0 2010-03-11 17:08 member -r--r--r--. 1 root root 0 2010-03-11 17:08 mls crw-rw-rw-. 1 root root 1, 3 2010-03-11 17:08 null dr-xr-xr-x. 2 root root 0 2010-03-12 10:54 policy_capabilities -r--r--r--. 1 root root 0 2010-03-11 17:08 policyvers -r--r--r--. 1 root root 0 2010-03-11 17:08 reject_unknown -rw-rw-rw-. 1 root root 0 2010-03-11 17:08 relabel -rw-rw-rw-. 1 root root 0 2010-03-11 17:08 user and before you ask, getenforce Permissive This particular system is kept fairly up-to-date (within a day or 2, if that helps)
(In reply to comment #15) > Created an attachment (id=399760) [details] > show strerror for security_getenforce > > Stephen could you take a look at this patch for libselinux? ACK. Dan, feel free to take that into the Fedora libselinux package and post it to selinux list for upstreaming.
/selinux/enforce is world readable as far as DAC goes and requires security_t:dir search and security_t:file read as far as SELinux is concerned. All of the dbus domains should have those permissions. Random possibilities: - His dbus instance is not running in the right domain? ps -eZ | grep dbus - His dbus instance is running in a chroot or private namespace and has no selinuxfs mounted or accessible there. - Dan is evil and took away those permissions from $1_dbusd_t domains.
(In reply to comment #18) > /selinux/enforce is world readable as far as DAC goes and requires > security_t:dir search and security_t:file read as far as SELinux is concerned. > All of the dbus domains should have those permissions. > Random possibilities: > - His dbus instance is not running in the right domain? ps -eZ | grep dbus > - His dbus instance is running in a chroot or private namespace and has no > selinuxfs mounted or accessible there. > - Dan is evil and took away those permissions from $1_dbusd_t domains. Wait - this is the session dbus, not the system dbus, right? So it is running in unconfined_t?
(In reply to comment #18) > /selinux/enforce is world readable as far as DAC goes and requires > security_t:dir search and security_t:file read as far as SELinux is concerned. > All of the dbus domains should have those permissions. > Random possibilities: > - His dbus instance is not running in the right domain? ps -eZ | grep dbus > - His dbus instance is running in a chroot or private namespace and has no > selinuxfs mounted or accessible there. > - Dan is evil and took away those permissions from $1_dbusd_t domains. Ohh - I didn't even think about it being the session bus, but scanning back up it has --session in the dbus-launch command which I should have noticed in the first place. I forgot that we use syslog for that too. Hmm, and we should really differentiate that more obviously in the log message. Anyways, in the absence of other ideas I'm going to commit my patches to dbus to make avc errors when selinux enabled be fatal. But we should still get to the bottom of why this is happening. Thom - are you using xguest or something like that? Can you post the output of: ps auxwZ ?
Colin - no, nothing like that. The "ps auxwZ" command didn't work. I did "ps -efZ|grep dbus" which should give you what you need: system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 dbus <pid> 1 0 <time> ? 00:00:02 dbus-daemon --system system_u:system_r:xdm_t:s0-s0:c0.c1023 root <pid> 1 0 <time> ? 00:00:00 dbus-launch --autolaunch <hex_string> --binary-syntax --close-stderr system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 root <pid> 1 0 <time> ? 00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 <user> <pid> 1 0 <time> ? 00:00:00 dbus-launch --sh-syntax --exit-with-session unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 <user> <pid> 1 0 <time> ? 00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root <pid> 1 0 <time> <terminal> 00:00:00 dbus-launch --autolaunch <hex_string> --binary-syntax --close-stderr unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root <pid> 1 0 <time> ? 00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
The libselinux strerror patch is present in libselinux 2.0.93 upstream.
That is not available via git?
cat nsalibselinux/VERSION 2.0.92
git pull worked for me. $ head libselinux/ChangeLog 2.0.93 2010-03-15 * Show strerror for security_getenforce() by Colin Waters. * Merged selabel database support by KaiGai Kohei. * Modify netlink socket blocking code by KaiGai Kohei. $ cat libselinux/VERSION 2.0.93
(In reply to comment #25) > git pull worked for me. > $ head libselinux/ChangeLog > 2.0.93 2010-03-15 > * Show strerror for security_getenforce() by Colin Waters. There's a typo in my name here =) Also FYI I posted a patch series to dbus upstream: http://lists.freedesktop.org/archives/dbus/2010-March/012377.html
Git repository is updated now.
libselinux-2.0.93-1.fc13 is in koji.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.