SELinux Blocking LDAP Connections

[Daniel J Walsh]

Justin Willmert wrote:

> Daniel J Walsh wrote:
>
>> Justin Willmert wrote:
>>
>>> Stephen Smalley wrote:
>>>
>>>> On Tue, 2005-06-28 at 18:22 -0500, Justin Willmert wrote:
>>>>  
>>>>
>>>>> Does anybody know of any problems with the new SELinux installed 
>>>>> in Fedora Core 4? I have OpenLDAP 2.2.23-5 installed and use it 
>>>>> for my user accounts. Fedora (throught the system-auth PAM module 
>>>>> and nsswitch) will log in correctly, but dovecot (version 
>>>>> 0.99.14-4.fc4) and apache (version 2.0.54-10) cannot connect to 
>>>>> the ldap server when SELinux is enabled. I use dovecot-ldap.conf 
>>>>> for dovecot to get the users and their home directories. In 
>>>>> Apache, I use basic authentication through LDAP to protect a 
>>>>> WebDAV accessible folder. For a long time, I thought Dovecot 
>>>>> wasn't working correctly, but after I set up Apache and it too 
>>>>> didn't work with OpenLDAP, I came to think that SELinux is 
>>>>> blocking something. Now the problem is I am not well enough 
>>>>> informed about SELinux to be able to debug where the problem may 
>>>>> reside.
>>>>>
>>>>> This is the message I get in /var/log/maillog when SELinux is 
>>>>> enabled:
>>>>>    Jun 28 17:21:14 netserv dovecot-auth: LDAP: ldap_result() 
>>>>> failed: Can't contact LDAP server
>>>>>
>>>>> And this is the error I get in /etc/httpd/logs/mydomain.com-error_log
>>>>>    [Tue Jun 28 17:21:37 2005] [warn] [client 192.168.1.1] [5962] 
>>>>> auth_ldap authenticate: user myuser authentication failed; URI 
>>>>> /calendars/ [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP 
>>>>> server]
>>>>>
>>>>> I can get you SELinux contexts for certain files if you need them, 
>>>>> but I don't have a clue on which ones to include.
>>>>>   
>>>>
>>>>
>>>>
>>>>
>>>> Look in /var/log/audit/audit.log, particularly for messages with the
>>>> type=AVC prefix.  SELinux permission denials are now logged there 
>>>> by the
>>>> audit daemon (previously they would go to /var/log/messages).  And
>>>> report them to fedora-selinux-list.
>>>>
>>>>  
>>>>
>>> Ok. I've been told (as you can see above) to report this problem to 
>>> this list instead of fedora-list (Just used a mailing list for the 
>>> first time yesterday, so I'm still learning about them). As you can 
>>> see above, I'm having a problem with SELinux and Dovecot and Apache. 
>>> After looking through my audit.log file, these are the lines I 
>>> thought were most important.
>>>
>>> This is what I found concerning apache:
>>>
>>>    type=AVC msg=audit(1119048563.037:3670666): avc:  denied  {
>>>    name_connect } for pid=6051 comm="httpd" dest=389      
>>> scontext=root:system_r:httpd_t
>>>    tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket
>>>    type=SOCKETCALL msg=audit(1119048563.054:3670776): nargs=3 a0=19
>>>    a1=8347e80 a2=10
>>>    type=SOCKADDR msg=audit(1119048563.054:3670776):
>>>    saddr=02000185C0A801940000000000000000
>>>    type=SYSCALL msg=audit(1119048563.054:3670776): arch=40000003
>>>    syscall=102 success=no exit=-13 a0=3 a1=bfcf1ad0 a2=3c94cb8 a3=19
>>>    items=0 pid=6052 auid=4294967295 uid=0 gid=48 euid=0 suid=0 fsuid=0
>>>    egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd"
>>>
>>> And this is what I found concerning Dovecot:
>>>
>>>    type=AVC msg=audit(1119053800.290:1566630): avc:  denied  { read }
>>>    for  pid=7472 comm="dovecot" name=stderr dev=tmpfs ino=2345
>>>    scontext=root:system_r:dovecot_t tcontext=system_u:object_r:device_t
>>>    tclass=lnk_file
>>>    type=PATH msg=audit(1119053800.291:1566631): item=0 name="/dev"
>>>    inode=534 dev=00:0d mode=040755 ouid=0 ogid=0 rdev=00:00
>>>    type=SYSCALL msg=audit(1119053800.291:1566631): arch=40000003
>>>    syscall=33 success=no exit=-13 a0=94e8100 a1=2 a2=94e8100 a3=739ca0
>>>    items=1 pid=7472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
>>>    egid=0 sgid=0 fsgid=0 comm="dovecot" exe="/usr/sbin/dovecot"
>>>    type=AVC msg=audit(1119053800.291:1566631): avc:  denied  { write }
>>>    for  pid=7472 comm="dovecot" name=/ dev=tmpfs ino=534
>>>    scontext=root:system_r:dovecot_t tcontext=system_u:object_r:device_t
>>>    tclass=dir
>>>    type=PATH msg=audit(1119053900.137:1641147): item=0
>>>    name="/dev/stderr" inode=534 dev=00:0d mode=040755 ouid=0 ogid=0
>>>    rdev=00:00
>>>
>>> Both of these sets were repeated multiple times throughout the log.
>>>
>>> Justin Willmert
>>>
>>> -- 
>>> fedora-selinux-list mailing list
>>> fedora-selinux-list at redhat.com
>>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>>
>>
>> You can allow httpd to connect via the boolean
>> setsebool -P httpd_can_network_connect=1
>>
>> Any idea what dovecot is trying to create in the /dev directory?
>>
>> Dan
>>
> OK, I've reset the boolean, but I can't really test it because if I 
> enable SELinux again, dovecot is going to stop working.
>
> To the issue of what dovecot is doing to /dev, your guess is as good 
> as mine. When I still ran FC3, I was using the University of 
> Washington IMAP server, but FC4 wouldn't allow me to use it, so I 
> upgraded to Dovecot. I'm still learning about it, so I have no clue it 
> is trying to do to my /dev directory. I guess it's an issue I can look 
> into (or someone can tell me if they know...It'd be faster ^_^ )
>
> Justin

If you run enforcing=0 for SELinux you should be able to get the error 
messages, without enforcing the errors. So dovecot would work.

Dan

--