SELinux is preventing /usr/sbin/bitlbee from 'getattr' accesses on the file /var/run/bitlbee.pid. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that bitlbee should be allowed getattr access on the bitlbee.pid file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep /usr/sbin/bitlbee /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:bitlbee_t:s0 Target Context system_u:object_r:var_run_t:s0 Target Objects /var/run/bitlbee.pid [ file ] Source bitlbee Source Path /usr/sbin/bitlbee Port <Neznámé> Host (removed) Source RPM Packages bitlbee-3.0.1-7.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.12-2.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.37-0.rc7.git0.2.fc15.x86_64 #1 SMP Wed Dec 22 17:12:22 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen St 29. prosinec 2010, 13:23:38 CET Last Seen St 29. prosinec 2010, 13:23:38 CET Local ID f5a94147-cbda-4350-bbf4-5ab10393e091 Raw Audit Messages type=AVC msg=audit(1293625418.864:2925): avc: denied { getattr } for pid=26937 comm="bitlbee" path="/var/run/bitlbee.pid" dev=tmpfs ino=3926108 scontext=system_u:system_r:bitlbee_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file bitlbee,bitlbee_t,var_run_t,file,getattr type=SYSCALL msg=audit(1293625418.864:2925): arch=x86_64 syscall=fstat success=yes exit=0 a0=6 a1=7fff0e77e1b0 a2=7fff0e77e1b0 a3=7fff0e77e7d0 items=0 ppid=1 pid=26937 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=bitlbee exe=/usr/sbin/bitlbee subj=system_u:system_r:bitlbee_t:s0 key=(null) bitlbee,bitlbee_t,var_run_t,file,getattr #============= bitlbee_t ============== allow bitlbee_t var_run_t:file getattr;
This is about switching bitlbee to be a systemd service, rather than a xinetd one. jakoubek:selinux# ausearch -m AVC -ts recent|grep bitlbee|audit2allow #============= bitlbee_t ============== allow bitlbee_t ircd_port_t:tcp_socket name_bind; allow bitlbee_t self:capability { sys_nice dac_override }; #!!!! The source type 'bitlbee_t' can write to a 'dir' of the following types: # var_lib_t, bitlbee_tmp_t, bitlbee_var_t, tmp_t, root_t allow bitlbee_t var_run_t:dir { write add_name }; #!!!! The source type 'bitlbee_t' can write to a 'file' of the following types: # bitlbee_tmp_t, bitlbee_var_t, root_t allow bitlbee_t var_run_t:file { write create open getattr }; allow bitlbee_t var_run_t:sock_file create;
(of course, just to emphasize, change to systemd is only for Fedora 15+).
Created attachment 471059 [details] updated version of the policy module When loading the module created in comment 1, and restarting bitlbee, I've got (in Permissive mode): SELinux is preventing /usr/sbin/bitlbee from 'remove_name' accesses on the directory bitlbee.sock. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that bitlbee should be allowed remove_name access on the bitlbee.sock directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep /usr/sbin/bitlbee /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:bitlbee_t:s0 Target Context system_u:object_r:var_run_t:s0 Target Objects bitlbee.sock [ dir ] Source bitlbee Source Path /usr/sbin/bitlbee Port <Neznámé> Host (removed) Source RPM Packages bitlbee-3.0.1-7.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.12-2.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.37-0.rc7.git0.2.fc15.x86_64 #1 SMP Wed Dec 22 17:12:22 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen St 29. prosinec 2010, 14:57:56 CET Last Seen St 29. prosinec 2010, 14:57:56 CET Local ID 54cfa40b-8efc-4d05-b666-54a54943fe40 Raw Audit Messages type=AVC msg=audit(1293631076.212:3053): avc: denied { remove_name } for pid=30042 comm="bitlbee" name="bitlbee.sock" dev=tmpfs ino=3926107 scontext=system_u:system_r:bitlbee_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir bitlbee,bitlbee_t,var_run_t,dir,remove_name type=AVC msg=audit(1293631076.212:3053): avc: denied { unlink } for pid=30042 comm="bitlbee" name="bitlbee.sock" dev=tmpfs ino=3926107 scontext=system_u:system_r:bitlbee_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file bitlbee,bitlbee_t,var_run_t,dir,remove_name type=SYSCALL msg=audit(1293631076.212:3053): arch=x86_64 syscall=unlink success=yes exit=0 a0=466d63 a1=ffffffff a2=1 a3=7fff0da7c000 items=0 ppid=1 pid=30042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=bitlbee exe=/usr/sbin/bitlbee subj=system_u:system_r:bitlbee_t:s0 key=(null) bitlbee,bitlbee_t,var_run_t,dir,remove_name #============= bitlbee_t ============== allow bitlbee_t var_run_t:dir remove_name; allow bitlbee_t var_run_t:sock_file unlink; Attached policy module fixes the issue.
Why does it need dac_override? Why is is binding to ircd_port_t?
(In reply to comment #4) > Why does it need dac_override? No idea. Robert? > Why is is binding to ircd_port_t? bitlbee is IRC gateway to other IM protocols (XMPP/Jabber in this case), i.e., it pretends to be an IRC server (and be logged in with an IRC client) and from the other side it connects to various IM protocols. Previously bitlbee was run as xinetd service (so xinetd got the ircd_port_t), but now we are switching to running bitlbee as a daemon, so it has to accquire the port on its own.
(In reply to comment #5) > (In reply to comment #4) > > Why does it need dac_override? > > No idea. Robert? No idea, too. Is that maybe related to the /var/lib/bitlbee usage?
What is the ownership/permissions on /var/lib/bitlbee and its contents?
(In reply to comment #7) > What is the ownership/permissions on /var/lib/bitlbee and its contents? jakoubek:~# ls -lRZ /var/lib/bitlbee/ /var/lib/bitlbee/: -rw-------. bitlbee bitlbee system_u:object_r:bitlbee_var_t:s0 mcepl.otr_fprints -rw-------. bitlbee bitlbee system_u:object_r:bitlbee_var_t:s0 mcepl.otr_keys -rw-------. bitlbee bitlbee system_u:object_r:bitlbee_var_t:s0 mcepl.xml -rw-------. bitlbee bitlbee system_u:object_r:bitlbee_var_t:s0 mcepl.xml.aCtKZp -rw-------. bitlbee bitlbee system_u:object_r:bitlbee_var_t:s0 mcepl.xml.YZuErd jakoubek:~# ls -ldZ /var/lib/bitlbee/ drwx------. bitlbee bitlbee system_u:object_r:bitlbee_var_t:s0 /var/lib/bitlbee/ jakoubek:~#
That's it. Bitlbee daemon is running under root and can not access to /var/lib/bitlbee
Why isn't it running under the bitlebee user?
(In reply to comment #9) > That's it. Bitlbee daemon is running under root and can not access to > /var/lib/bitlbee I am not sure I understand, bitlbee runs as root (which is mistake, it should be user bitlbee -- maybe this is just some preliminary unfinished work, it did not show up lately), but it runs as scontext=system_u:system_r:bitlbee_t:s0. So, how come it doesn't have access to bitlbee_var_t? However, truth is that I haven't seen this for some time, so it is probably gone anyway. Feel free to close (after replying to my question though first, please).
This avc says that the root account does not have access to /var/lib/bittlebee via standard DAC controls, without root using one of its "Super Powers" dac_override. The problem is bittlebee is supposed to run as the bittlebee UID, but for some reason when this AVC happened it was running as UID=0, which caused the AVC.