Bug 434600 - Bitlbee produces avc denial
Bitlbee produces avc denial
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2008-02-22 19:36 EST by Casey Dahlin
Modified: 2014-06-18 04:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-20 10:06:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Casey Dahlin 2008-02-22 19:36:45 EST
Description of problem:

Version-Release number of selected component (if applicable):

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

setroubleshoot says:

    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 #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
Comment 1 Robert Scheck 2008-02-23 10:35:44 EST
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.
Comment 2 Daniel Walsh 2008-02-26 09:38:20 EST
THis is a avc about bitlbee trying to connect to port 443?  Is this expected
Comment 3 Robert Scheck 2008-02-26 09:59:56 EST
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.
Comment 4 Casey Dahlin 2008-02-26 10:19:31 EST
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.
Comment 5 Daniel Walsh 2008-02-26 16:47:25 EST
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

Comment 6 Casey Dahlin 2008-10-19 14:30:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.