Is Squid not returning some data you need on a SE Linux system?
The default configuration of the SE Linux policy for Squid only allows it to connect to a small number of ports which are used for web servers. For example ports http (80) and https (443) are labelled as http_port_t which permits serves such as Apache to bind to them and Squid to connect to them. But sometimes services run on non-standard ports and periodically new services are devised which use the HTTP protocol and thus you have Squid and Apache using new ports.
semanage port -a -t http_port_t -p tcp 11371
One example of such a port is hkp (11371) – the latest protocol for sending and receiving GPG/OpenPGP keys. Running the above command relabelled the TCP port 11371 in question as http_port_t and thus allowed everything to work.
setsebool -P squid_connect_any 1
An alternate option would be to run the above command to allow Squid to connect to any port.
I will suggest that the upstream policy be changed to make the default labelling of TCP port 11371 be http_port_t, but the same operations can be used for other ports.
Some people may claim that this makes things difficult for sys-admins. But the fact is that a well known port is a significant resource that you don’t want to permit any random user to access. Not only do the SE Linux port access controls prevent malice, but they also prevent system programs from accidentally using the wrong ports. A common example of accidental mis-use is the port 631 used for the IPP (Internet Printing Protocol – CUPS). When system programs need to use TCP source ports below 1024 they start at 1023 and work their way down, having such programs get down to 631 is not uncommon (there are some error conditions which result in ports being reserved for some minutes after use). In terms of malicious operations, it seems that the ports used by database servers such as MySQL and PostgreSQL would ideally be inaccessible to a Squid proxy, and services such as network backup should be inaccessible to everything other than the backup software.
Another related issue I have with the selinux port policy is that I think it’s quite bad that port numbers are hard coded in the policy and can’t be removed. Why should the policy care about port numbers, and not just labels ?
# semanage port -d -p tcp 80
/usr/sbin/semanage: Port tcp/80 is defined in policy, cannot be deleted
I ended up running squid unconfined on a system because the old system had squid on port 80, and I couldn’t easily reconfigure all clients :-(
Good point. That bug also applies to fcontext entries.