Description of problem: I'm getting a SELinux AVC denial when connecting to the server with Jabbim. host=toshiba-user.lan type=AVC msg=audit(1207267004.41:116): avc: denied { read } for pid=12548 comm="ldconfig" path="/usr/share/jabbim/plugins/autoaway/autoaway.py" dev=dm-0 ino=642495 scontext=unconfined_u:unconfined_r:ldconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file host=toshiba-user.lan type=SYSCALL msg=audit(1207267004.41:116): arch=c000003e syscall=59 success=yes exit=0 a0=930cc0 a1=930050 a2=92f170 a3=0 items=0 ppid=12547 pid=12548 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts3 ses=9 comm="ldconfig" exe="/sbin/ldconfig" subj=unconfined_u:unconfined_r:ldconfig_t:s0-s0:c0.c1023 key=(null) Version-Release number of selected component (if applicable): jabbim-0.4-0.2.20080403svn.fc9.noarch python-2.5.1-24.fc9.x86_64 glibc-2.7.90-13.x86_64 selinux-policy-targeted-3.3.1-26.fc9.noarch kernel-2.6.25-0.185.rc7.git6.fc9.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run jabbim 2. Make sure you have autoaway plugin enabled 3. Set online status. Actual results: The AVC is reported. Jabbim runs fine. Expected results: No AVC message should appear. Additional info: Jabbim's autoaway plugin uses Python's ctypes module to load libX11 and libXss. It does this: xlib = ctypes.cdll.LoadLibrary(find_library("X11")) It's the find_library() function which does tricks with ldconfig. It is implemented in /usr/lib64/python2.5/ctypes/util.py and does: os.popen('/sbin/ldconfig -p 2>/dev/null')
I tried using strace to find a syscall failing with EACCES, but didn't find anything relevant. So I used systemtap to find where exactly in the kernel the AVC denial is happening and got this backtrace: 0xffffffff8106d0e9 : audit_log_start+0x1/0x396 0xffffffff8111092c : avc_audit+0x79/0x9c8 0xffffffff819b7dc0 : packet_exit+0x498c0a/0x7e0e0e4a 0xffffffff81110885 : avc_has_perm_noaudit+0x45d/0x48b 0xffffffff819be138 : packet_exit+0x49ef82/0x7e0e0e4a 0xffffffff811112c9 : avc_has_perm+0x4e/0x60 0xffffffff81112ed6 : inode_has_perm+0x5b/0x61 0xffffffff810120aa : sched_clock+0x50/0x6d 0xffffffff81112ffd : file_has_perm+0x84/0x8f 0xffffffff81051b6d : lock_release_holdtime+0x1e/0x108 # flush_unauthorized_files is inlined here 0xffffffff81117159 : selinux_bprm_post_apply_creds+0x1c5/0x424 0xffffffff810120aa : sched_clock+0x50/0x6d 0xffffffff8110d963 : security_bprm_post_apply_creds+0xe/0x10 0xffffffff810b1c58 : compute_creds+0xc9/0xce 0xffffffff810e2639 : load_elf_binary+0xe99/0x1730 0xffffffff810120aa : sched_clock+0x50/0x6d 0xffffffff813ece58 : __stop_notes+0x13c5c4/0x22176c 0xffffffff813ece40 : __stop_notes+0x13c5ac/0x22176c 0xffffffff810e17a0 : load_elf_binary+0x0/0x1730 0xffffffff813f23c0 : __stop_notes+0x141b2c/0x22176c 0xffffffff810e17a0 : load_elf_binary+0x0/0x1730 0xffffffff810b1a0c : search_binary_handler+0xca/0x24d 0xffffffff810b2d3d : do_execve+0x1b8/0x24e 0xffffffff8100a62c : sys_execve+0x3e/0x59 0xffffffff8100c48a : stub_execve+0x6a/0xc0 This tells me Jabbim (or Python itself) execs ldconfig, but it leaves a fd open for reading for autoaway.py (and archive.py, I'm seeing a second denial for that one).
Created attachment 300408 [details] close the plugin source file's fd before instantiating the plugin I have it. Jabbim leaves the plugin's source file open after doing load_source on it. Then it creates an instance of the plugin which then runs ldconfig -p. The fix is to close the file before calling the plugin's constructor.
Upstream applied the patch in SVN revision 2563.