issues when the host is running SELinux
Opened this issue · 6 comments
Not advocating SELinux here, but
$ sudo docker run --net host -v /var/squid3/cache:/var/squid3/cache jpetazzo/squid-in-a-can
squid3: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied
Setting MAXIMUM_OBJECT_SIZE 1024
Setting DISK_CACHE_SIZE 5000
Traceback (most recent call last):
File "/tmp/deploy_squid.py", line 72, in <module>
sys.exit(main())
File "/tmp/deploy_squid.py", line 54, in main
subprocess.check_call(build_cmd, shell=True)
File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'squid3 -z' returned non-zero exit status 127
Setting permissive mode on the host let's the container start up.
Interesting, thanks! I'm not using SELinux on my machine so I never saw this.
Would you like to add a paragraph to the README, to explain that if you get this error with SELinux, then you might need to set permissive mode and explain how?
then you might need to set permissive mode and explain how?
Dan Walsh will probably cringe hearing that 😄
There's a WIP documentation for working with SELinux and Docker; moby/moby#11396
There are some hints and links from Dan in there that may help trying to solve this in an "approved" way. I'm no SELinux expert myself, but perhaps it's useful.
(Don't want to "ping" Dan for each SELinux question, but he's quite helpful)
Hi, I revisited this today.
The specific selinux error is 'execmod' was denied for the squid3 binary. The following policy fixes this (but it's quite a wide additional permission and a better policy can probably be crafted)
module mypol 1.0;
require {
type svirt_sandbox_file_t;
type svirt_lxc_net_t;
class file execmod;
}
#============= svirt_lxc_net_t ==============
allow svirt_lxc_net_t svirt_sandbox_file_t:file execmod;
(install with sudo semodule -i mypol.pp)
However, for my own purposes I solved this by rebasing on RHEL, which doesn't seem to trigger the same problem (CentOS is probably OK too, haven't tried): https://github.com/jmtd/squid-in-a-can/tree/rhel
Thanks for reporting your findings! I'll close this issue, and I hope that if others have a similar problem, they'll be able to find it along with your solution :-)
I know this issue is long closed but I think there is a better answer for it.
I believe this issue is that the stock squid image contains text relocations. Selinux configurations consider that this is a programming error and block it with the execmod option. execmod can prevent certain types of exploit and is worth having enabled.
This can be fixed in squid with -fPIC like the patch centos uses when compiling squid:
You can test a binary for text relocations like so:
readelf -d squid | fgrep TEXTREL
Rather than disable this security protection in selinux, it may be preferable to compile squid in a way which allows it to take advantage of the security mechanisms selinux provides.