Description of problem: SSIA Version-Release number of selected component (if applicable): 1.0.4-1.fc8 Steps to Reproduce: Start bitlbee as a system service, then connect to it with an irc client and identify (you may need to do less than this, this is what I'd done when I noticed the issue (I run permissive, so functionality was not actually prevented). I have 2 aim accounts, an ICQ account, an msn account and a yahoo account). setroubleshoot says: Summary SELinux is preventing /usr/sbin/bitlbee (bitlbee_t) "name_connect" to <Unknown> (http_port_t). Detailed Description SELinux denied access requested by /usr/sbin/bitlbee. It is not expected that this access is required by /usr/sbin/bitlbee and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:bitlbee_t:SystemLow-SystemHigh Target Context system_u:object_r:http_port_t Target Objects None [ tcp_socket ] Affected RPM Packages bitlbee-1.0.4-1.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall Host Name baudrillard Platform Linux baudrillard 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 16:35:26 EST 2008 i686 i686 Alert Count 1 First Seen Fri 22 Feb 2008 07:17:47 PM EST Last Seen Fri 22 Feb 2008 07:17:47 PM EST Local ID a6b8835e-dafe-4f98-92d8-c65a3b02ecde Line Numbers Raw Audit Messages avc: denied { name_connect } for comm=bitlbee dest=443 egid=493 euid=497 exe=/usr/sbin/bitlbee exit=-115 fsgid=493 fsuid=497 gid=493 items=0 pid=3415 scontext=system_u:system_r:bitlbee_t:s0-s0:c0.c1023 sgid=493 subj=system_u:system_r:bitlbee_t:s0-s0:c0.c1023 suid=497 tclass=tcp_socket tcontext=system_u:object_r:http_port_t:s0 tty=(none) uid=497
Daniel, can you take this as policy maintainer? IMHO this is not a bitlbee issue itself, but a SELinux one. What me confuses is the http_port_t, because bitlbee normally binds itself to *:6667 or similar which are reserved for IRC as per IANA. If needed, please flip the report back to me, please.
THis is a avc about bitlbee trying to connect to port 443? Is this expected behaviour?
What? That sounds as a configuration thing caused by the reporter. Bitlbee binds itself as per default configuration only to localhost:6667. Another useful binding could be *:6667 or a similar IRC port, but bitlbee has nothing to do with port 443 (https) except somebody configures bitlbee to act there. But if the standard settings are changed such drastically, this is NOTABUG and has to be worked around/solved somehow else by the reporter IMHO.
I didn't do anything interesting to bitlbee's configuration. The other possibility is that selinux is doing what it's supposed to do. I.e. someone is trying to exploit a vulnerability in bitlbee on my machine.
I extracted the source code and this is what I find. grep -r 443 bittlebee ./protocols/msn/passport.c: ssl = ssl_connect( "nexus.passport.com", 443, passport_retrieve_dalogin_connected, rep ); ./protocols/msn/passport.c: ssl = ssl_connect( server, 443, passport_get_id_connected, rep ); ./protocols/msn/passport.c: if( ssl_connect( server, 443, passport_get_id_connected, rep ) ) grep: ./.#TODO: No such file or directory You can allow this for now by executing # audit2allow -M mypol -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.0.8-89.fc8
I don't think I've seen this in a bit. I have selinux-policy-3.3.1-99 now. I'm allright with calling this fixed.