Bug 1877443

I have confirmed an selinux error even after a full relabel of the filesystem:  

type=AVC msg=audit(1600099983.157:162127): avc:  denied  { name_connect } for  pid=60845 comm="diagnostic_con*" dest=53 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:dns_port_t:s0 tclass=tcp_socket permissive=0
type=AVC msg=audit(1600099983.157:162128): avc:  denied  { name_connect } for  pid=60845 comm="diagnostic_con*" dest=53 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:dns_port_t:s0 tclass=tcp_socket permissive=0

I set selinux to permissive and  it worked.  I recieved the following in the audit.log:

type=AVC msg=audit(1600110859.989:3095): avc:  denied  { name_connect } for  pid=4392 comm="diagnostic_con*" dest=53 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:dns_port_t:s0 tclass=tcp_socket permissive=1

It seems there needs to be an selinux policy update.  What is strange, is if we set the config to point to a name with a single ip address, it works.

lzap, can you please take a look? look like something in the selinux changes from 6.7 caused dns lookups to fail when there are multiple ips resolved for the ldap server hostname.

From a working Satellit 6.7.2:  

$ getsebool -a | grep foreman
httpd_run_foreman --> on
passenger_run_foreman --> on


From the 6.8 beta:  

$  getsebool -a | grep foreman
foreman_rails_can_connect_all --> off
foreman_rails_can_connect_container_unix --> on
foreman_rails_can_connect_http --> on
foreman_rails_can_connect_http_proxy --> on
foreman_rails_can_connect_ldap --> on
foreman_rails_can_connect_libvirt --> on
foreman_rails_can_connect_openstack --> on
foreman_rails_can_connect_smtp --> on
foreman_rails_can_listen_any --> off
foreman_rails_can_spawn_ssh --> on
passenger_run_foreman --> off

SELinux info about the error:  

type=AVC msg=audit(1600111635.572:3201): avc:  denied  { name_connect } for  pid=4399 comm="diagnostic_con*" dest=53 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:dns_port_t:s0 tclass=tcp_socket permissive=1
        Was caused by:
        The boolean foreman_rails_can_connect_all was set incorrectly. 
        Description:
        Allow foreman to rails can connect all
        Allow access by executing:
        # setsebool -P foreman_rails_can_connect_all 1

Compared the above to another Satellite 6.8.  The only difference is that passenger_run_foreman is on.  I tried turning it on, and tested again.  Same result.

I attempted the test with foreman_rails_can_connect_all on, and it worked.  I feel this may "enable too much", as it works for a single domain controller without that boolean enabled.

Hello, Foreman SELinux policy maintainer here.

This was caused by our switch from Apache httpd to Puma application server. Apache was likely allowed to perform this operation, I can't find the rule in the base policy tho. Interesting fact - Satellite in their environment makes TCP request not UDP request for some reason. This is typical behavior when DNS response is larger than UDP limit - server sends special response "ask me again using TCP" and client does that.

The rule we are missing is

corenet_tcp_connect_dns_port(foreman_rails_t)

It is probably better to allow more generic

sysnet_dns_name_resolve(foreman_rails_t)

which also takes DNSSEC into account. I will prepare the patch, in the meantime you can try to compile a custom policy with the mentioned rule (sysnet_...) if you can to confirm the fix. Thank you!

> This was caused by our switch from Apache httpd to Puma application server. Apache was likely allowed to perform this operation

Alternatively, this customers environment simply has too many DNS records and their past environment did fit into UDP packet limit. This could explain why I could not find this rule in Apache httpd policy.

Upstream bug assigned to lzap

Upstream bug assigned to lzap

In reference to comment 16, the amount of dns records has not changed.  The only change is the satellite code/selinux policy from 6.7.2 to 6.8.0 beta.  

I performed the following:  

1) manually modified the file /usr/share/doc/foreman-selinux-2.1.0/foreman.te per the PR
2) Changed line 19 as follows:

--policy_module(foreman, @@VERSION@@)
++policy_module(foreman, 2.1.0.1)

3) yum install selinux-policy-devel --disableplugin foreman-protector
3) make -f /usr/share/selinux/devel/Makefile
4) /usr/sbin/semodule -i foreman.pp
5) foreman-maintain service restart (just for good measure)

The connection test worked, so I saved the config using the 42 domain A records, and logged out and back in.  Test successful.  

Thanks for looking into this, and the quick work on a solution!

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/30845 has been resolved.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.8 release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4366