CentOS - Apr 2017 - NOT Solved - Re: SELinux policy to allow Dovecot to connect to Mysql

Robert,

in regards to your Postfix and Dovecot issue with MySQL and SELinux,
> Apr 26 01:25:45 z9m9z dovecot: dict: Error: 
> mysql(/var/lib/mysql/mysql.sock): Connect failed to database 
> (postfix): Can't connect to local MySQL server through socket 
> '/var/lib/mysql/mysql.sock' (13) - waiting for 1 seconds before
retry
> Apr 26 01:25:45 z9m9z dovecot: dict: Error: dict sql lookup failed: 
> Not connected to database
>
A Google search brought up this write-up of how William (a Red Hat engineer in
Australia) faced this in 2011 and was able to solve the issue. His blog still
has recent posts in 2017, so you might want to browse the "about
 page and contact him directly to discuss the post.

See:
http://firstyear.id.au/blog/html/2011/07/05/SELinux_for_postfix_+_dovecot.html
 
On this post referenced above, the author has a sample SELinux policy for
postfix/dovecot and mysql.
While the post references an e-mail setup guide link that is no longer
reachable, the policy file is still present in text.
 
This URL: https://mgrepl.fedorapeople.org/man_selinux/Fedora18/mysqld.html 
has a good summary of the Booleans available for the MySQL SELinux policy

For Dovecot, you will need a policy that allows the dovecot process to
transition from whatever context it is currently running into the applicable
context that is defined for the mysqld process (or at least some SELinux context
that permits access to the socket.)

Cheers!

Simba
Engineering

thanks.

On 04/26/2017 08:55 AM, Phoenix, Merka wrote:
> Robert,
>
> in regards to your Postfix and Dovecot issue with MySQL and SELinux,
>
>> Apr 26 01:25:45 z9m9z dovecot: dict: Error:
>> mysql(/var/lib/mysql/mysql.sock): Connect failed to database
>> (postfix): Can't connect to local MySQL server through socket
>> '/var/lib/mysql/mysql.sock' (13) - waiting for 1 seconds before
retry
>> Apr 26 01:25:45 z9m9z dovecot: dict: Error: dict sql lookup failed:
>> Not connected to database
>>
> A Google search brought up this write-up of how William (a Red Hat engineer
in Australia) faced this in 2011 and was able to solve the issue. His blog still
has recent posts in 2017, so you might want to browse the "about
>   page and contact him directly to discuss the post.
>
> See:
http://firstyear.id.au/blog/html/2011/07/05/SELinux_for_postfix_+_dovecot.html
This page is about postfix and mysql, not dovecot and mysql.  It does 
validate the allow that is failing on my system:

allow dovecot_t mysqld_t:unix_stream_socket connectto;

>   
> On this post referenced above, the author has a sample SELinux policy for
postfix/dovecot and mysql.
> While the post references an e-mail setup guide link that is no longer
reachable, the policy file is still present in text.
>   
> This URL: https://mgrepl.fedorapeople.org/man_selinux/Fedora18/mysqld.html
> has a good summary of the Booleans available for the MySQL SELinux policy
I have read this a number of times and it does not seem to offer any help.
>
> For Dovecot, you will need a policy that allows the dovecot process to
transition from whatever context it is currently running into the applicable
context that is defined for the mysqld process (or at least some SELinux context
that permits access to the socket.)
It seems that what I need is

allow dovecot_t mysqld_t:unix_stream_socket connectto;

But the policy generates errors.  I will have to submit a bug report, it 
seems

> Simba
> Engineering
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

On 04/26/2017 12:29 AM, Robert Moskowitz wrote:
> But the policy generates errors.  I will have to submit a bug report, 
> it seems 

A bug report would probably be helpful.

I'm looking back at the message you wrote describing errors in 
ld-2.17.so.  I think what's happening is that the policy on your system 
includes a silent rule that somehow breaks your system. You'll need to 
turn on debugging (logging the otherwise silent AVCs) to figure this 
out, in order to provide information that the maintainers can use to 
actually fix the problem.

So, similar to the previous process:

1: semodule -DB
2: setenforce permissive
3: tail -f /var/log/audit/audit.log | grep AVC
4: use the service, exercise each function that's constrained by the 
existing policy
5: copy and paste the output from the terminal used for #2 into 
"audit2allow -M <modulename>"
6: setenforce enforcing
7: semodule -B

You'll want to do this with your custom policy installed.  In the 
terminal that's following audit.log, you should now see AVCs logged that 
you didn't before.  Please send them to the list.

If you're only interested in resolving your problem, it should be 
sufficient to build one new module with the AVCs logged here.  If you 
want to produce a useful bug report and fix the problem for the future, 
for everyone, you need to first get back into enforcing mode and THEN 
build a new module with each individual AVC, installing each one and 
then testing dovecot, until you resolve the problem, and then removing 
all of the other new modules until you confirm that you've found one (or 
a minimal combination) of rules that is causing dovecot to crash and log 
a backtrace.