I’ve been wrestling with squid today, and although I have inky stains on my body and soul, I’ve made some headway. I’ve been trying to be a good sysadmin and not just disable selinux, or set it to permissive and forget it, at the first sign of trouble. Thing is, I wanted a non-default squid configuration, and selinux got in the way. I had two problems that I had to solve – non standard listen ports, and non-standard cache location.
I installed squid with the usual yum install squid command on my CentOS 5.4 server. I want to be able to use a single squid instance to support both configured browsers (on the basis that it’s better if browsers know they are being proxied) and transparent (sometimes called “intercept”) proxying for applications with their own http access libraries, and guest machines on my network that may not want to configure my proxy settings, or don’t respect autoconfigure via DHCP. So, after using webmin to set up a few basics, I jumped into the /etc/squid/squid.conf file and set up the following:
# Listen on internal address for VLAN 2
http_port 10.254.225.65:3128
http_port 10.254.225.65:3129 transparent
# Listen on internal address for VLAN 3
http_port 10.254.225.129:3128
http_port 10.254.225.129:3129 transparent
I then used Webmin to create a new logical volume on my RAID array, a nice healthy 64GB. Big for a cache, but I want to try and cache installers and downloaded updates, so I want plenty of space. I created the logical volume, mounted it on /webcache and jumped back into squid config in Webmin and added a cache location /webcache of 5000MB, 16 1st-level folders and 256 2nd-level folders.
Squid failed to start. OK, I thought, I’ll initialise the cache with squid -z. That ran fine as root. Squid still wouldn’t start. A check of the log files showed that squid was complaining “cache_dir /webcache: (13) Permission denied“. Of course, I hadn’t set permissions on /webcache, so a quick chown -R squid:squid /webcache and I thought I was done. I was not – squid still wouldn’t start.
I realised selinux might be the culprit and checked this by running setenforce Permissive and lo and behold, squid started. A review of /var/log/audit/audit.log suggested that there were two problems – the non-standard port 3129 and the non-standard cache location.
The port issue was relatively easy to fix. semanage port -l | grep "cache" to list any selinux information about ports that cache processes are allowed to use suggested the following:
http_cache_port_t tcp 3128, 8080, 8118, 11211, 10001-10010
http_cache_port_t udp 3130, 11211
So, I needed to add port 3129 to the list. A quick Google found a note about adding non-standard Apache ports, and from that is was easy to work out that the magic line would be semanage port -a -t http_cache_port_t -p tcp 3129 which adds port 3129 to the list of allowed ports for http caches. I didn’t expect this to get squid running, but at least the next failure gave me a smaller set of audit log entries to work on!
Next, I needed to fix the file contexts for /webcache. This was a little more complex, being a novice to selinux. I discovered that I could view existing context with ls -Z so at least I could assess my efforts. I also found that it’s possible to change the file context with chcon, but this may not survive reboots, a restorecon (restore contexts) command or a “relabel” of the filesystem. I needed a way to make sure that selinux knew that /webcache was meant to be used for squid, so I disn’t have to keep telling it.
After some poking around, and trying a few things out to no avail, I found that I needed to use a command grep -hi "squid" /etc/selinux/targeted/contexts/files/file_contexts* which showed me where the selinux policy knew about allowable locations for squid to keep files, as follows:
/etc/squid(/.*)? system_u:object_r:squid_conf_t:s0
/var/log/squid(/.*)? system_u:object_r:squid_log_t:s0
/var/squidGuard(/.*)? system_u:object_r:squid_cache_t:s0
/var/spool/squid(/.*)? system_u:object_r:squid_cache_t:s0
/usr/share/squid(/.*)? system_u:object_r:squid_conf_t:s0
/var/cache/squid(/.*)? system_u:object_r:squid_cache_t:s0
/var/log/squidGuard(/.*)? system_u:object_r:squid_log_t:s0
/usr/sbin/squid -- system_u:object_r:squid_exec_t:s0
/var/run/squid\.pid -- system_u:object_r:squid_var_run_t:s0
/usr/lib/squid/cachemgr\.cgi -- system_u:object_r:httpd_squid_script_exec_t:s0
/usr/lib64/squid/cachemgr\.cgi -- system_u:object_r:httpd_squid_script_exec_t:s0
So, it seems all I needed to do was to add to that list, and all would be good. There was a small wrinkle to this too though. semanage fcontext -a -t squid_cache_t /webcache would seem to do the necessary magic, but in fact semanage fcontext doesn’t work like a regular filesystem tool, so there’s no recursion. It didn’t seem “clean” to then iterate through each sub-folder (all 4096 of them!) and set the context.
The answer was actually simple. Delete the cache folders with rm -rf /webcache/0* and rm -rf /webcache/swap* and then set the required context on /webcache in the policy with semanage fcontext -a -t squid_cache_t /webcache and finally make this the current context with restorecon -R /webcache. Then, with context set in the parent folder, running squid -z meant that the 4096 cache directories were also created with the right context.
I re-enabled Enforcing mode, squid started and my selinux policy is aware of my non-standard configuration, so hopefully future updates won’t break it. My small concern is that future updates to the selinux policy may overwrite my changes – I don’t know how selinux works well enough to know if my policy changes will survive or be overwritten. At least I’ve got my own handy guide to how to make it work again if I need it…
Recent Comments