Thanks Laurent. You obviously know a LOT more about SELinux than I. I pretty much just use commands and not build policies. So I need some more information here.

From what you provided below, how do I determine what is currently in place and how do I add your stuff (changing postgresql with mysql, nat.)

thanks

On 04/25/2017 10:26 AM, Laurent Wandrebeck wrote:

Le mardi 25 avril 2017 à 10:04 +0200, Robert Moskowitz a écrit :

...

I thought I had this fixed, but I do not. I was away from this problem working on other matters, and came back (after a reboot) and it is still there, so I suspect when I thought I had it 'fixed' I was running with setenforce 0 from another problem (that is fixed).

So anyone know how to get dovecot dict connecting to mysql when enforcing? Googling is not finding any real help.

Hi,

I’ve got some « tweaking » here (using postgresql, obviously) so that dovecot runs properly with SELinux enabled,

HTH, Laurent.

module mydovecot 1.0;

require { type dovecot_auth_t; type postgresql_port_t; type dovecot_t; type var_t; type postfix_virtual_tmp_t; class tcp_socket name_connect; class file { rename read lock create write getattr link unlink open append }; class dir { read write create add_name remove_name }; }

#============= dovecot_auth_t ==============

#!!!! This avc is allowed in the current policy allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect;

#============= dovecot_t ==============

#!!!! This avc is allowed in the current policy allow dovecot_t postfix_virtual_tmp_t:file { rename write unlink open link }; allow dovecot_t var_t:dir create;

#!!!! This avc is allowed in the current policy allow dovecot_t var_t:dir { read write add_name remove_name };

#!!!! This avc is allowed in the current policy allow dovecot_t var_t:file { rename read lock create write getattr link unlink open append };

On 04/25/2017 10:58 AM, Laurent Wandrebeck wrote:

Le mardi 25 avril 2017 à 10:39 +0200, Robert Moskowitz a écrit :

...

Thanks Laurent. You obviously know a LOT more about SELinux than I. I pretty much just use commands and not build policies. So I need some more information here.

From what you provided below, how do I determine what is currently in place and how do I add your stuff (changing postgresql with mysql, nat.)

thanks

Quick’n’(really) dirty SELinux howto:

1. Run the service. fails due to missing selinux policy.
2. grep service_pattern /var/log/audit/audit.log | audit2allow -M

myservice_policy

Do you really mean 'service_pattern', or is this a placeholder for something like mysql?

As I get 'Nothing to do'

3. do what output says. (semodule -i myservice_policy.pp normally)
4. goto 1. That way, you’ll create and allow step by step necessary

rights so your service ends up running normaly.

The content I gave you is from mydovecot.te (human readable version of .pp created by audit2allow).

After a quick look at audit2allow man, it looks like you can get .pp by doing: make -f /usr/share/selinux/devel/Makefile myservice_policy.pp (it’ll look after myservice_policy.te in PWD).

HTH,

On 04/25/2017 11:12 AM, Laurent Wandrebeck wrote:

Le mardi 25 avril 2017 à 11:07 +0200, Robert Moskowitz a écrit :

...

On 04/25/2017 10:58 AM, Laurent Wandrebeck wrote:

...

Le mardi 25 avril 2017 à 10:39 +0200, Robert Moskowitz a écrit :

...

Thanks Laurent. You obviously know a LOT more about SELinux than I. I pretty much just use commands and not build policies. So I need some more information here.

From what you provided below, how do I determine what is currently in place and how do I add your stuff (changing postgresql with mysql, nat.)

thanks

Quick’n’(really) dirty SELinux howto:

1. Run the service. fails due to missing selinux policy.
2. grep service_pattern /var/log/audit/audit.log | audit2allow -M

myservice_policy

Do you really mean 'service_pattern', or is this a placeholder for something like mysql?

As I get 'Nothing to do'

placeholder which changes according to your needs.

I just made it worst. I put in mysql for myservice_policy, got a /pp and did:

semodule -i myservice_policy.pp

Now I get real errors like:

Apr 25 05:13:16 z9m9z dovecot: dict: Error: b6fa1000-b6fc0000 r-xp 00000000 08:03 6076 /usr/lib/ld-2.17.so Apr 25 05:13:16 z9m9z dovecot: dict: Error: b6fc5000-b6fc7000 rw-p 00000000 00:00 0 Apr 25 05:13:16 z9m9z dovecot: dict: Error: b6fcd000-b6fcf000 rw-p 00000000 00:00 0 Apr 25 05:13:16 z9m9z dovecot: dict: Error: b6fcf000-b6fd0000 r--p 0001e000 08:03 6076 /usr/lib/ld-2.17.so Apr 25 05:13:16 z9m9z dovecot: dict: Error: b6fd0000-b6fd1000 rw-p 0001f000 08:03 6076 /usr/lib/ld-2.17.so Apr 25 05:13:16 z9m9z dovecot: dict: Error: bee46000-bee67000 rw-p 00000000 00:00 0 [stack] Apr 25 05:13:16 z9m9z dovecot: dict: Error: beec5000-beec6000 r-xp 00000000 00:00 0 [sigpage] Apr 25 05:13:16 z9m9z dovecot: dict: Error: ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]

Which go away if I setenforce 0. :(

myservice_policy.te has:

module myservice_policy 1.0;

require { type dovecot_t; type mysqld_etc_t; type mysqld_t; class unix_stream_socket connectto; class file { getattr open read }; class dir read; }

#============= dovecot_t ============== allow dovecot_t mysqld_etc_t:dir read; allow dovecot_t mysqld_etc_t:file { getattr open read };

#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock #!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode' allow dovecot_t mysqld_t:unix_stream_socket connectto;

On 04/25/2017 11:29 AM, Laurent Wandrebeck wrote:

Le mardi 25 avril 2017 à 11:19 +0200, Robert Moskowitz a écrit :

...

/usr/lib/ld-2.17.so

This file is not part of CentOS 7, nor CentOS 6 ?

I am running Centos 7 armv7hl

So it IS possible that I am missing something that did not get built right for armv7hl. We are often finding rpms that built, but did not get into the repo...

So what provides ld-2.17.so for Centos 7 so I can backtrack it?

On 04/25/2017 11:41 AM, Laurent Wandrebeck wrote:

Le mardi 25 avril 2017 à 11:36 +0200, Robert Moskowitz a écrit :

...

On 04/25/2017 11:29 AM, Laurent Wandrebeck wrote:

...

Le mardi 25 avril 2017 à 11:19 +0200, Robert Moskowitz a écrit :

...

/usr/lib/ld-2.17.so

This file is not part of CentOS 7, nor CentOS 6 ?

I am running Centos 7 armv7hl

So it IS possible that I am missing something that did not get built right for armv7hl. We are often finding rpms that built, but did not get into the repo...

So what provides ld-2.17.so for Centos 7 so I can backtrack it?

.org/mailman/listinfo/centos

Oh. I haven’t found out anything via yum provides on x86_84, that may explain why.

Maybe someone running armv7hl could help, I don’t own such hardware running CentOS.

There is always QEMM emulation of armv7... :)

That *may* be a armv7hl port bug, I’m afraid I can’t help you more on that point :-/

On 04/25/2017 06:45 PM, Gordon Messmer wrote:

On 04/25/2017 01:58 AM, Laurent Wandrebeck wrote:

...

Quick’n’(really) dirty SELinux howto:

Alternate process:

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

This process is less iterative, which can save a *lot* of time building some policies.

How do I undo the damage the last attempt caused?

I am on the road right now (Venice, IT to speak tomorrow on Identity Oriented Networking), and I left my test system running back home. To get to it is two SSH hops. The WiFi in this hotel is a pain. It times out after 1 hour and you have to do a web access. It does not understand things like IMAP and SSH...

On 04/25/2017 09:34 PM, Gordon Messmer wrote:

On 04/25/2017 12:05 PM, Robert Moskowitz wrote:

...

How do I undo the damage the last attempt caused?

I'm not sure what damage you mean.

If you installed a custom selinux module already and want to remove it, look at the files in /etc/selinux/targeted/modules/active/modules/.

Nothing there. But I found entries with the same name I installed under

/etc/selinux/targeted/active/modules/400

Those are the modules you've installed. Use "semodule -r <modulename>" to remove the ones you don't need.

So I tried this and it failed:

# semodule -r myservice_policy.pp libsemanage.semanage_direct_remove_key: Unable to remove module myservice_policy.pp at priority 400. (No such file or directory). semodule: Failed!

But it is there:

# ls /etc/selinux/targeted/active/modules/400/ -ls total 4 4 drwx------. 2 root root 4096 Apr 25 05:10 myservice_policy

# ls /etc/selinux/targeted/active/modules/400/myservice_policy/ -ls total 12 4 -rw-r--r--. 1 root root 177 Apr 25 05:10 cil 4 -rw-r--r--. 1 root root 325 Apr 25 05:10 hll 4 -rw-r--r--. 1 root root 2 Apr 25 05:09 lang_ext

Do I simply delete these files?

On 04/25/2017 06:45 PM, Gordon Messmer wrote:

On 04/25/2017 01:58 AM, Laurent Wandrebeck wrote:

...

Quick’n’(really) dirty SELinux howto:

Alternate process:

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

This process is less iterative, which can save a *lot* of time building some policies.

This made the same content as before that caused problems:

module myservice_policy 1.0;

require { type dovecot_t; type mysqld_etc_t; type mysqld_t; class unix_stream_socket connectto; class file { getattr open read }; class dir read; }

#============= dovecot_t ============== allow dovecot_t mysqld_etc_t:dir read; allow dovecot_t mysqld_etc_t:file { getattr open read };

#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock #!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode' allow dovecot_t mysqld_t:unix_stream_socket connectto;

What do these 3 comments mean? I don't think I want to restorecon for a socket:

# ls -Z /var/lib/mysql -rw-rw----. mysql mysql system_u:object_r:mysqld_db_t:s0 aria_log.00000001 -rw-rw----. mysql mysql system_u:object_r:mysqld_db_t:s0 aria_log_control -rw-rw----. mysql mysql system_u:object_r:mysqld_db_t:s0 ibdata1 -rw-rw----. mysql mysql system_u:object_r:mysqld_db_t:s0 ib_logfile0 -rw-rw----. mysql mysql system_u:object_r:mysqld_db_t:s0 ib_logfile1 drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql srwxrwxrwx. mysql mysql system_u:object_r:mysqld_var_run_t:s0 mysql.sock drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 performance_schema drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 postfix drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 roundcubemail

What does the 3rd comment mean?

thanks

On 04/26/2017 04:22 AM, Gordon Messmer wrote:

On 04/25/2017 03:25 PM, Robert Moskowitz wrote:

...

This made the same content as before that caused problems:

I still don't understand, exactly. Are you seeing *new* problems after installing a policy? What are the problems?

...

#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock #!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode' allow dovecot_t mysqld_t:unix_stream_socket connectto;

What do these 3 comments mean?

I'm not sure about the first two. The context you see is the same I see on the one system where I run mysqld. Running restorecon doesn't change that context.

As for the latter, it sounds like you should be able to remove your custom policy and "setsebool -P daemons_enable_cluster_mode 1" to allow dovecot to connect to mysql.

did not work. it was set off, so I turned it on and tried it out. Got the same errors:

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

You would think that the mysql people would have a boolean to allow specific apps to access the socket.

And document it.

On 04/25/2017 10:29 PM, Robert Moskowitz wrote:

did not work. it was set off, so I turned it on and tried it out. Got the same errors:

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

OK. Re-install the policy, "tail -f /var/log/audit/audit.log" and then try to use dovecot. You're looking for an AVC. What do you see?

You would think that the mysql people would have a boolean to allow specific apps to access the socket.

That's not how SELinux works. The policy on mysql doesn't control what clients do. The clients have their own policies (or don't, many apps run unconfined).

On 26/04/17 17:29, Robert Moskowitz wrote:

On 04/26/2017 04:22 AM, Gordon Messmer wrote:

...

On 04/25/2017 03:25 PM, Robert Moskowitz wrote:

...

This made the same content as before that caused problems:

I still don't understand, exactly. Are you seeing *new* problems after installing a policy? What are the problems?

...

#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock #!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode' allow dovecot_t mysqld_t:unix_stream_socket connectto;

What do these 3 comments mean?

I'm not sure about the first two. The context you see is the same I see on the one system where I run mysqld. Running restorecon doesn't change that context.

As for the latter, it sounds like you should be able to remove your custom policy and "setsebool -P daemons_enable_cluster_mode 1" to allow dovecot to connect to mysql.

did not work. it was set off, so I turned it on and tried it out. Got the same errors:

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

how have you specified your mysql server host? as localhost, 127.0.0.1 or as the hosts IP address? In my experience it needs to be localhost or 127.0.0.1 and these are also defined in /etc/hosts hth

You would think that the mysql people would have a boolean to allow specific apps to access the socket.

And document it.

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

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.ht...

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

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.

Gordon,

Thank you for your help on this. Still not working...

On 04/26/2017 06:27 PM, Gordon Messmer wrote:

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.

Here are the messages I got:

type=AVC msg=audit(1493361695.041:49205): avc: denied { rlimitinh } for pid=3047 comm="cleanup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361695.041:49205): avc: denied { siginh } for pid=3047 comm="cleanup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361695.041:49205): avc: denied { noatsecure } for pid=3047 comm="cleanup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361695.978:49206): avc: denied { rlimitinh } for pid=3052 comm="lmtp" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_smtp_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361695.978:49206): avc: denied { siginh } for pid=3052 comm="lmtp" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_smtp_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361695.978:49206): avc: denied { noatsecure } for pid=3052 comm="lmtp" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_smtp_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361698.775:49208): avc: denied { rlimitinh } for pid=3056 comm="smtpd" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_smtpd_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361698.775:49208): avc: denied { siginh } for pid=3056 comm="smtpd" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_smtpd_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361698.775:49208): avc: denied { noatsecure } for pid=3056 comm="smtpd" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_smtpd_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361699.102:49209): avc: denied { rlimitinh } for pid=3057 comm="auth" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:system_r:dovecot_auth_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361699.102:49209): avc: denied { siginh } for pid=3057 comm="auth" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:system_r:dovecot_auth_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361699.102:49209): avc: denied { noatsecure } for pid=3057 comm="auth" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:system_r:dovecot_auth_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361699.950:49210): avc: denied { rlimitinh } for pid=3063 comm="pipe" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_pipe_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361699.950:49210): avc: denied { siginh } for pid=3063 comm="pipe" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_pipe_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361699.950:49210): avc: denied { noatsecure } for pid=3063 comm="pipe" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_pipe_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361700.073:49211): avc: denied { rlimitinh } for pid=3064 comm="deliver" scontext=system_u:system_r:postfix_pipe_t:s0 tcontext=system_u:system_r:dovecot_deliver_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361700.073:49211): avc: denied { siginh } for pid=3064 comm="deliver" scontext=system_u:system_r:postfix_pipe_t:s0 tcontext=system_u:system_r:dovecot_deliver_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361700.073:49211): avc: denied { noatsecure } for pid=3064 comm="deliver" scontext=system_u:system_r:postfix_pipe_t:s0 tcontext=system_u:system_r:dovecot_deliver_t:s0 tclass=process permissive=1 type=AVC msg=audit(1493361700.724:49212): avc: denied { open } for pid=3068 comm="dict" path="/etc/my.cnf.d" dev="sda3" ino=12779 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:mysqld_etc_t:s0 tclass=dir permissive=1 type=USER_AVC msg=audit(1493361722.244:49216): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: received setenforce notice (enforcing=0) exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

I made the policy, applied it, and set my standard sendmail test:

sendmail -i testit3@test.htt-consult.com < /usr/share/doc/amavisd-new-2.10.1/test-messages/README

It failed accessing mysql with the following maillog messages:

Apr 28 02:55:11 z9m9z postfix/pickup[1554]: 8A0124CDA: uid=0 from=<root> Apr 28 02:55:11 z9m9z postfix/cleanup[3354]: 8A0124CDA: message-id=20170428065511.8A0124CDA@z9m9z.test.htt-consult.com Apr 28 02:55:11 z9m9z postfix/qmgr[6166]: 8A0124CDA: from=root@z9m9z.test.htt-consult.com, size=1424, nrcpt=1 (queue active) Apr 28 02:55:11 z9m9z amavis[7341]: (07341-17) NOTICE: reconnecting in response to: err=2006, HY000, DBD::mysql::st execute failed: MySQL server has gone away at (eval 129) line 172. Apr 28 02:55:11 z9m9z amavis[7341]: (07341-17) LMTP [127.0.0.1]:10024 /var/spool/amavisd/tmp/amavis-20170427T030938-07341-6TygUJMr: root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com SIZE=1424 Received: from z9m9z.test.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.test.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP for testit3@test.htt-consult.com; Fri, 28 Apr 2017 02:55:11 -0400 (EDT) Apr 28 02:55:11 z9m9z amavis[7341]: (07341-17) Checking: A2vWsL1r3nYT [127.0.0.1] root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com Apr 28 02:55:13 z9m9z postfix/smtpd[3363]: connect from localhost[127.0.0.1] Apr 28 02:55:14 z9m9z postfix/smtpd[3363]: 564C049E2: client=localhost[127.0.0.1], orig_client=unknown[127.0.0.1] Apr 28 02:55:14 z9m9z postfix/cleanup[3354]: 564C049E2: message-id=20170428065511.8A0124CDA@z9m9z.test.htt-consult.com Apr 28 02:55:14 z9m9z postfix/qmgr[6166]: 564C049E2: from=root@z9m9z.test.htt-consult.com, size=2136, nrcpt=1 (queue active) Apr 28 02:55:14 z9m9z postfix/smtpd[3363]: disconnect from localhost[127.0.0.1] Apr 28 02:55:14 z9m9z amavis[7341]: (07341-17) A2vWsL1r3nYT FWD from root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com, BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 564C049E2 Apr 28 02:55:14 z9m9z amavis[7341]: (07341-17) Passed CLEAN {RelayedInbound}, [127.0.0.1] root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com, Message-ID: 20170428065511.8A0124CDA@z9m9z.test.htt-consult.com, mail_id: A2vWsL1r3nYT, Hits: 2.973, size: 1424, queued_as: 564C049E2, 2645 ms Apr 28 02:55:14 z9m9z postfix/lmtp[3359]: 8A0124CDA: to=testit3@test.htt-consult.com, relay=127.0.0.1[127.0.0.1]:10024, delay=3.3, delays=0.47/0.11/0.03/2.7, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 564C049E2) Apr 28 02:55:14 z9m9z postfix/qmgr[6166]: 8A0124CDA: removed Apr 28 02:55:15 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 28 02:55:15 z9m9z dovecot: lda(testit3@test.htt-consult.com): Error: Internal quota calculation error Apr 28 02:55:15 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 28 02:55:15 z9m9z dovecot: dict: Error: dict sql lookup failed: Not connected to database Apr 28 02:55:15 z9m9z dovecot: lda(testit3@test.htt-consult.com): Error: Internal quota calculation error Apr 28 02:55:15 z9m9z dovecot: lda(testit3@test.htt-consult.com): sieve: msgid=20170428065511.8A0124CDA@z9m9z.test.htt-consult.com: stored mail into mailbox 'INBOX' Apr 28 02:55:15 z9m9z postfix/pipe[3370]: 564C049E2: to=testit3@test.htt-consult.com, relay=dovecot, delay=0.9, delays=0.14/0.15/0/0.62, dsn=2.0.0, status=sent (delivered via dovecot service) Apr 28 02:55:15 z9m9z postfix/qmgr[6166]: 564C049E2: removed

I set SELinux to permissive and it works:

Apr 28 02:57:53 z9m9z postfix/pickup[1554]: DF38F4CDA: uid=0 from=<root> Apr 28 02:57:54 z9m9z postfix/cleanup[3419]: DF38F4CDA: message-id=20170428065753.DF38F4CDA@z9m9z.test.htt-consult.com Apr 28 02:57:54 z9m9z postfix/qmgr[6166]: DF38F4CDA: from=root@z9m9z.test.htt-consult.com, size=1424, nrcpt=1 (queue active) Apr 28 02:57:54 z9m9z amavis[7342]: (07342-17) LMTP [127.0.0.1]:10024 /var/spool/amavisd/tmp/amavis-20170426T190541-07342-ifG0CeGq: root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com SIZE=1424 Received: from z9m9z.test.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.test.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP for testit3@test.htt-consult.com; Fri, 28 Apr 2017 02:57:54 -0400 (EDT) Apr 28 02:57:54 z9m9z amavis[7342]: (07342-17) Checking: wWh0cdDyySoD [127.0.0.1] root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com Apr 28 02:57:55 z9m9z postfix/smtpd[3427]: connect from localhost[127.0.0.1] Apr 28 02:57:56 z9m9z postfix/smtpd[3427]: 428694AC1: client=localhost[127.0.0.1], orig_client=unknown[127.0.0.1] Apr 28 02:57:56 z9m9z postfix/cleanup[3419]: 428694AC1: message-id=20170428065753.DF38F4CDA@z9m9z.test.htt-consult.com Apr 28 02:57:56 z9m9z postfix/qmgr[6166]: 428694AC1: from=root@z9m9z.test.htt-consult.com, size=2136, nrcpt=1 (queue active) Apr 28 02:57:56 z9m9z postfix/smtpd[3427]: disconnect from localhost[127.0.0.1] Apr 28 02:57:56 z9m9z amavis[7342]: (07342-17) wWh0cdDyySoD FWD from root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com, BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 428694AC1 Apr 28 02:57:56 z9m9z amavis[7342]: (07342-17) Passed CLEAN {RelayedInbound}, [127.0.0.1] root@z9m9z.test.htt-consult.com -> testit3@test.htt-consult.com, Message-ID: 20170428065753.DF38F4CDA@z9m9z.test.htt-consult.com, mail_id: wWh0cdDyySoD, Hits: 2.973, size: 1424, queued_as: 428694AC1, 2232 ms Apr 28 02:57:56 z9m9z postfix/lmtp[3424]: DF38F4CDA: to=testit3@test.htt-consult.com, relay=127.0.0.1[127.0.0.1]:10024, delay=2.9, delays=0.47/0.11/0.03/2.3, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 428694AC1) Apr 28 02:57:56 z9m9z postfix/qmgr[6166]: DF38F4CDA: removed

So these additional policies stop all the memory errors, but still leave me not working with SELinux.

When I get home Monday, I am going to rebuild the server. With my Howtos, this is not so hard. It could be that with all the testing, I dropped something in that I should not have.

If I still have this problem, then it is bug report time.

And then I will do it one AVC at a time with the policy building.

Again, thanks

On Fri, 28 Apr 2017, Gordon Messmer wrote:

On 04/28/2017 12:06 AM, Robert Moskowitz wrote:

...

Here are the messages I got:

type=AVC msg=audit(1493361695.041:49205): avc: denied { rlimitinh } for pid=3047 comm="cleanup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=process permissive=1

My advice would be to slow down, and solve one problem at a time. We were talking about testing dovecot, and now you're testing postfix. I know you need them both to work, but these are separate services, with their own individual policies. If you're going to submit a bug report, you need to be able to specifically describe the problem and the solution. You're not going to do that by mixing different services together.

...

sendmail -i testit3@test.htt-consult.com < /usr/share/doc/amavisd-new-2.10.1/test-messages/README

It failed accessing mysql with the following maillog messages:

Yes, but the policy you added earlier only granted MySQL access to dovecot. For postfix, you'll want to check for booleans first and then create a policy (without debugging AVCs) if no boolean exists, and then look at debugging AVCs if there are still issues (which is *almost* never the case).

...

When I get home Monday, I am going to rebuild the server.

That would be good. Keep a log of *all* of the changes you make to the system, from the very beginning. Once you resolve the problem, rebuild the server again and follow your log.

+1 to what Gordon said. It is the only way you are going to figure it out.

You could use something like Ansible so that you can rebuild the server the same way in about 20 minutes. Yes, it takes time to get Ansible or something similar to work but once you do, you can build the same thing as many times as you need and they are always the same.

Just a thought.

Regards,

On 04/28/2017 06:36 PM, Gordon Messmer wrote:

On 04/28/2017 12:06 AM, Robert Moskowitz wrote:

...

Here are the messages I got:

type=AVC msg=audit(1493361695.041:49205): avc: denied { rlimitinh } for pid=3047 comm="cleanup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=process permissive=1

My advice would be to slow down, and solve one problem at a time.

I failed to look at the content of these messages and see that there was also a problem with postfix accessing mysql. I was not getting any errors about this in maillog.

We were talking about testing dovecot, and now you're testing postfix.

I would have to think a bit about how to test dovecot accessing mysql without it processing an email handed off to it by postfix.

I know you need them both to work, but these are separate services, with their own individual policies. If you're going to submit a bug report, you need to be able to specifically describe the problem and the solution. You're not going to do that by mixing different services together.

Nope. But I see now there is a broader problem.

...

sendmail -i testit3@test.htt-consult.com < /usr/share/doc/amavisd-new-2.10.1/test-messages/README

It failed accessing mysql with the following maillog messages:

Yes, but the policy you added earlier only granted MySQL access to dovecot. For postfix, you'll want to check for booleans first and then create a policy (without debugging AVCs) if no boolean exists, and then look at debugging AVCs if there are still issues (which is *almost* never the case).

So now I do some googling about postfix/mysql and SELinux. Probably a better discussed combination.

...

When I get home Monday, I am going to rebuild the server.

That would be good. Keep a log of *all* of the changes you make to the system, from the very beginning. Once you resolve the problem, rebuild the server again and follow your log.