relevant SELinux errors:

type=AVC msg=audit(1593522203.911:2410): avc:  denied  { name_connect } for  pid=22762 comm="diagnostic_con*" dest=3123 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0
type=SYSCALL msg=audit(1593522203.911:2410): arch=c000003e syscall=42 success=no exit=-13 a0=1b a1=134b8a20 a2=10 a3=2 items=0 ppid=22611 pid=22762 auid=4294967295 uid=994 gid=991 euid=994 suid=994 fsuid=994 egid=991 sgid=991 fsgid=991 tty=(none) ses=4294967295 comm="diagnostic_con*" exe="/opt/rh/rh-ruby25/root/usr/bin/ruby" subj=system_u:system_r:foreman_rails_t:s0 key=(null)
type=PROCTITLE msg=audit(1593522203.911:2410): proctitle=70756D613A20636C757374657220776F726B657220313A203232363131205B666F72656D616E5D
type=AVC msg=audit(1593522203.911:2411): avc:  denied  { name_connect } for  pid=22762 comm="diagnostic_con*" dest=3123 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0
type=SYSCALL msg=audit(1593522203.911:2411): arch=c000003e syscall=42 success=no exit=-13 a0=1b a1=1390de90 a2=1c a3=2 items=0 ppid=22611 pid=22762 auid=4294967295 uid=994 gid=991 euid=994 suid=994 fsuid=994 egid=991 sgid=991 fsgid=991 tty=(none) ses=4294967295 comm="diagnostic_con*" exe="/opt/rh/rh-ruby25/root/usr/bin/ruby" subj=system_u:system_r:foreman_rails_t:s0 key=(null)
type=PROCTITLE msg=audit(1593522203.911:2411): proctitle=70756D613A20636C757374657220776F726B657220313A203232363131205B666F72656D616E5D

This works already for normal http proxy ports (like 8080), but for other ports this selinux bool allows it:

setsebool foreman_rails_can_connect_all on

Ignore comment #2, the proper way to configure this is documented here:

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.7/html-single/installing_satellite_server_from_a_connected_network/index#configuring-selinux-to-ensure-access-on-custom-ports_satellite

going back as far as 6.4:
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.4/html/installing_satellite_server_from_a_connected_network/performing_additional_configuration_on_satellite_server

relevant text:


 SELinux ensures access of Red Hat Satellite 6 and Red Hat Subscription Manager only to specific ports. In the case of the HTTP cache, the TCP ports are 8080, 8118, 8123, and 10001 - 10010. If you use a port that does not have SELinux type http_cache_port_t, complete the following steps:

    To verify the ports that are permitted by SELinux for the HTTP cache, enter a command as follows:

    # semanage port -l | grep http_cache
    http_cache_port_t       tcp    8080, 8118, 8123, 10001-10010
    [output truncated]

    To configure SELinux to permit a port for the HTTP cache, for example 8088, enter a command as follows:

    # semanage port -a -t http_cache_port_t -p tcp 8088

For more information on SELinux port settings, see Section 1.9, “Changing Default SELinux ports”. 



So while i have confirmed that the beahvior has changed, this seems to work without configuration in 6.6, we have documented what needs to be done and I might consider the fact that it worked in older releases to be a bug.  I'm tempted to close this as NOTABUG.  Thoughts?

I would argue if 8080 is the only one normal http proxy port:

http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010

squid_port_t                   tcp      3128, 3401, 4827


IMO selinux policy should not only include connecting to http_cache_port_t but also squid_port_t

In automation we use 3128/tcp but that's already squid_port_t so we had to remove it first from squid_port_t label and add it to http_cache_port_t
So, we better reconfigure our proxies for port 8080/tcp

Justin, how do you confirm that "this works already for normal http proxy ports (like 8080)"?

I have proxy machine with squid. Squid listens on 3128 by default, but I changed that to 8080.
On Satellite machine, I can do thing like `curl -O -L "https://www.redhat.com/index.html" -x "myproxy.com:8080"` and they will work (I can see new connection in squid log).
In Satellite UI, I set up new proxy for the same address and when I click "Test connection", I still receive error.

In production.log, I see:
#v+
2020-06-30T10:23:00 [I|app|375a8de4] Started PUT "/http_proxies/test_connection" for 127.0.0.1 at 2020-06-30 10:23:00 -0400
2020-06-30T10:23:00 [I|app|375a8de4] Processing by HttpProxiesController#test_connection as */*
2020-06-30T10:23:00 [I|app|375a8de4]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"", "http_proxy"=>{"name"=>"proxy1", "url"=>"http://myproxy.com:8080", "username"=>"", "password"=>"[FILTERED]", "location_ids"=>["", "3"], "organization_ids"=>["", "1"]}, "fakepassword"=>"[FILTERED]", "test_url"=>"https://aws.amazon.com"}
2020-06-30T10:23:00 [D|tax|375a8de4] Current location set to Default Location/child location
2020-06-30T10:23:00 [D|tax|375a8de4] Current organization set to Default Organization
2020-06-30T10:23:00 [D|app|375a8de4] Unpermitted parameter: :test_url
2020-06-30T10:23:00 [D|app|375a8de4] RestClient.head "https://aws.amazon.com", "Accept"=>"*/*", "Accept-Encoding"=>"gzip, deflate", "User-Agent"=>"rest-client/2.0.2 (linux-gnu x86_64) ruby/2.5.5p157"

2020-06-30T10:23:00 [I|app|375a8de4] Completed 422 Unprocessable Entity in 160ms (Views: 0.6ms | ActiveRecord: 5.0ms | Allocations: 9798)
#v-

There are also these, which may or may not be related:
#v+
2020-06-30T10:23:06 [E|app|79a1d5e9] Error occurred while starting Katello::CandlepinEventListener
2020-06-30T10:23:06 [E|app|79a1d5e9] Permission denied - connect(2) for "localhost" port 61613
2020-06-30T10:23:06 [E|app|79a1d5e9] /opt/theforeman/tfm/root/usr/share/gems/gems/stomp-1.4.9/lib/connection/netio.rb:461:in `initialize'
/opt/theforeman/tfm/root/usr/share/gems/gems/stomp-1.4.9/lib/connection/netio.rb:461:in `open'
/opt/theforeman/tfm/root/usr/share/gems/gems/stomp-1.4.9/lib/connection/netio.rb:461:in `block in open_ssl_socket'
/opt/rh/rh-ruby25/root/usr/share/ruby/timeout.rb:76:in `timeout'
#v-

Hi Mirek,

The timeout error is unrelated.  I reproduced on an upstream nightly, where 3128 failed with the selinux error, but 8080 did not.  Is it possible to access that satellite?

Mirek, 

Thank you!   I do see different behavior in 6.8 compared to upstream so it looks like there is some underlying selinux bug.  

Talking with lzap it seems like maybe he has an idea, and using sesearch i can see upstream:

   allow foreman_rails_t http_cache_port_t : tcp_socket name_connect ; 

while this does not exist on 6.8.


Regardless even when this is fixed, you'll have to add the port according to the documentation.  I'll also leave it to lzap to answer why he squid ports aren't automatically part of http_cache_port_t

ANALYSIS:

In Satellite 6.6 passenger domain was allowed to connect to both mentioned types:

[root@sat66 ~]# sesearch --all -t http_cache_port_t | grep passenger
   dontaudit passenger_t defined_port_type : udp_socket name_bind ; 
   allow passenger_t http_cache_port_t : tcp_socket name_connect ; 
   allow passenger_t port_type : tcp_socket name_connect ; 
[root@sat66 ~]# sesearch --all -t squid_port_t | grep passenger
   dontaudit passenger_t defined_port_type : udp_socket name_bind ; 
   allow passenger_t squid_port_t : tcp_socket name_connect ; 
   allow passenger_t port_type : tcp_socket name_connect ; 

Now, in Satellite 6.8 we are moving away from passenger to puma, so the domain is different. While we haven't changed anything in our rules, these have been added somewhere in the base policy:

[root@sat68 ~]# sesearch --all -t http_cache_port_t | grep foreman
   dontaudit foreman_rails_t defined_port_type : udp_socket name_bind ; 
   dontaudit foreman_proxy_t defined_port_type : udp_socket name_bind ; 
   allow foreman_rails_t port_type : tcp_socket name_connect ; 
[root@sat68 ~]# sesearch --all -t squid_port_t | grep foreman
   dontaudit foreman_rails_t defined_port_type : udp_socket name_bind ; 
   dontaudit foreman_proxy_t defined_port_type : udp_socket name_bind ; 
   allow foreman_rails_t port_type : tcp_socket name_connect ; 

The fix is to add them explicitly, I will introduce a boolean that will be TURNED ON by default for better user experience. Security-enhanced environments may want to turn this off if needed.

There is more to allow for foreman_rails_t domain:

allow foreman_rails_t candlepin_activemq_port_t:tcp_socket name_connect;
allow foreman_rails_t tftpdir_rw_t:dir search;

Lukas.

> allow foreman_rails_t candlepin_activemq_port_t:tcp_socket name_connect;

This one was fixed in katello-selinux: https://projects.theforeman.org/issues/29603

If you don't see this, file a separate BZ as this will be a different change.

> allow foreman_rails_t tftpdir_rw_t:dir search;

Can you tell when do you encounter this denial? I'd like to know when this happens, this might be when bootdisk is being generated we now search in TFTP directory as well. If you can confirm, please file another BZ.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=1857194 for: 

> allow foreman_rails_t tftpdir_rw_t:dir search;

though not sure about reproducer, just default QE install reproduces the issue

Verified:

Verified with:
- Satellite 6.8.0 snap 10

Test steps:
1. Go to Infrastructure > Http Proxies > New Http Proxy
2. Provide Url and access credentials of proxy
3. Click on Test connection button.
4. Use proxy to to synchronize repository.

Observation:
- No error. Successful test connection.
- Content sync completed successfully.

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