Re: SELinux blocking Dovecot from mysqld socket

Lukas Vrabec <[email protected]>
Newsgroups gmane.linux.redhat.fedora.selinux
Organization Red Hat, Inc.
Message-ID <[email protected]>
On 2/6/19 10:59 AM, Ondrej Mosnacek wrote:
> On Tue, Feb 5, 2019 at 6:57 PM Robert Moskowitz <[email protected]> wrote:
>> On 2/5/19 10:41 AM, Ondrej Mosnacek wrote:
>>> On Tue, Feb 5, 2019 at 2:54 PM Robert Moskowitz <[email protected]> wrote:
>>>>
>>>>
>>>> On 2/5/19 3:23 AM, Zdenek Pytela wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Feb 4, 2019 at 9:03 PM Robert Moskowitz <[email protected]> wrote:
>>>>> I am working with Centos7:
>>>>>
>>>>> I have configured Dovecot to connect to mysqld via socket:
>>>>>
>>>>> connect = host=/var/lib/mysql/mysql.sock dbname=postfix user=postfix
>>>>> password=Postfix_Database_Password
>>>>>
>>>>> I test sending a message with
>>>>>
>>>>> sendmail -i [email protected] < README
>>>>>
>>>>> This fails with the following message in maillog
>>>>>
>>>>> Feb  4 11:28:48 klovia dovecot: dict(13122): 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 25 seconds before retry
>>>>>
>>>>> If I setenforce to 0, the connection works.  So it clearly is an SELinux
>>>>> problem.  I worked on this almost 2 years ago on another system and found:
>>>>>
>>>>> http://zszsit.blogspot.com/2012/12/dovecot-mysql-selinux-issue-on-centos6.html
>>>>>
>>>>> But I was hoping that there were better tools now with Centos7.  I
>>>>> checked for setsebool at:
>>>>>
>>>>> https://linux.die.net/man/8/mysqld_selinux
>>>>>
>>>>> and tried:
>>>>>
>>>>> setsebool -P allow_user_mysql_connect 1
>>>>>
>>>>> But the mail still does not go unless I setenforce to 0.
>>>> Hi,
>>>>
>>>> this boolean allows a different permission - see the manual page:
>>>>>> If you want to allow users to connect to mysql, you must turn on the allow_user_mysql_connect boolean.
>>>>> Is there someway to get SELinux to allow dovecot (and postfix) to
>>>>> connect to mysqld?
>>>> While dovecot is allowed to connect to postgresql port, there is no similar permission for mysql:
>>>>
>>>> # sesearch -A -s dovecot_t -c tcp_socket -p name_connect | grep sql
>>>> allow dovecot_t postgresql_port_t:tcp_socket name_connect;
>>>>
>>>> However, if this permission is the only one missing, you can simply add it with:
>>>>
>>>> # echo '(allow dovecot_t mysqld_port_t (tcp_socket (name_connect)))' > dovecot-mysql.cil
>>>> # semodule -i dovecot-mysql.cil
>>>> # sesearch -A -s dovecot_t -c tcp_socket -p name_connect | grep sql
>>>> allow dovecot_t mysqld_port_t:tcp_socket name_connect;
>>>> allow dovecot_t postgresql_port_t:tcp_socket name_connect;
>>>>
>>>>
>>>> Still getting the error.  This does not seem to be what is needed.  Isn't this to open TCP access where I am using the unix socket interface?
>>> Indeed, what Zdenek advised is for allowing to connect via TCP. Could
>>> you try the following instead?
>>>
>>> dnf install selinux-policy-devel
>>
>> Nit this is CentOS7, so yum.  In fact it is CentOS7-armhfp...
>>
>>> cat >dovecot_mysql.te <<EOF
>>> policy_module(dovecot_mysql,1.0.0)
>>> gen_require(`
>>>         type dovecot_t;
>>> ')
>>> mysql_read_config(dovecot_t)
>>> mysql_stream_connect(dovecot_t)
>>> EOF
>>
>> For some reason this made an empty file.  Don't know if it was the lack
>> of spaces on that first line?  I use this myself a lot, but always put
>> spaces around the > and <<
> 
> As other have already pointed out, it was because of the unescaped
> backtick. I initially started with just the last two lines and later
> realized the other lines are also needed, so I just vim'd the file and
> copy-pasted the new contents into the e-mail without checking if it
> still works :)
> 
>>
>> So I just used vi this time.  :)
>>
>>> make -f /usr/share/selinux/devel/Makefile dovecot_mysql.pp
>>
>>> semodule -i dovecot_mysql.pp
>>
>> And the sendmail test went through with enforcing.
>>
>> thanks!
> 
> Great! I submitted a PR to allow this in Fedora policy, since it seems
> like a valid use case. Hopefully it gets to RHEL/CentOS from there
> eventually.
> 
> https://github.com/fedora-selinux/selinux-policy-contrib/pull/86
> 

Thanks Ondrej, for PR, it's already merged and back ported to Fedora 28
and Fedora 29.

https://github.com/fedora-selinux/selinux-policy-contrib/commit/e7c5f327c12dac498cfef69f9a4f9a3d57fa8677

Robert,

Do you have some more SELinux denials (AVC msgs) in audit.log after
workaround from Ondrej? If yes, please attach it , we can work on them.

Thanks,
Lukas.

> --
> Ondrej Mosnacek <omosnace at redhat dot com>
> Associate Software Engineer, Security Technologies
> Red Hat, Inc.
> _______________________________________________
> selinux mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
> 


-- 
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

_______________________________________________
selinux mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE3wrP3ArXoyYgAS7LRyAaxC8pzgYFAlxasS0ACgkQRyAaxC8p
zgb3aAf9HH8MbH5rE3vLxg5uMwOxa1Mylu1zhV7zouvTthsrTeQARgxSQPmkJo2L
2QclvaO7JVBO68LsLL6G0XO9SQV8Gk6kmKrHCrqAX1NZVOwwJOXHiBPh1Ix1Sx55
Pa8mCuK2TkvcU2OawmopUgqYX/UR5cIu3XzxgfZ27Iu1JLkVHxSa5H+ytXJeI/oY
tCCWnzxH7p3daAEPtaBe6ODvzbHh9Xn6TsDpBxDJlT0e1MQ2Sn9xmnB3PNGBfuas
61lpF1kPD/PUaLt/YvJyED3wGvtGxqCxRaIlmF1hJNd73B6Q/EvdPrS4F89sJBiH
vWzp5B/3DpjGA+6zk9gRSfs2QWyB3Q==
=oFZ/
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.