issues when the host is running SELinux

[jmtd]

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.

[jpetazzo]

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?

[thaJeztah]

then you might need to set permissive mode and explain how?

Dan Walsh will probably cringe hearing that :smile:

There's a WIP documentation for working with SELinux and Docker; https://github.com/docker/docker/pull/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)

[jmtd]

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

[jpetazzo]

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 :-)

[jamorham]

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:

https://git.centos.org/blob/rpms!squid/6dd3ac8a383c4c3f67659c4c15e95b9e27ffc2ef/SOURCES!squid-3.2.0.9-fpic.patch

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.

[jpetazzo]

@jamorham: excellent investigation, thanks for finding this out! I'm not maintaining this image anymore, but if someone wants to submit a PR (e.g. to switch to CentOS or any other build that avoids text relocations) or even take over maintenance, I'll be happy to help.