Bug 1310198

On my Rawhide box I can start squid without any errors from systemctl with SELinux in enforcing mode. I also saw no errors in the journal.

This was with squid-3.5.13-1.fc24.x86_64.

I am now able to reproduce this error on Fedora Rawhide, so I retract my statement from comment 1. Squid does not start on Rawhide or Fedora 23, and I suspect that it also does not start on Fedora 24 though I have not tested this yet.

I believe that the difference in my tests between February and March was due to using a similar squid.conf as Brian attached. In February my test only used the stock configuration.

Hello, on what Fedora version, have you tested it on?

I installed the latest squid from testing repository: 

rpm -qa squid
squid-3.5.10-2.fc23.x86_64

I have not experienced any issues, by installing squid and starting it.

Process:

1) # yum install https://kojipkgs.fedoraproject.org//packages/squid/3.5.10/2.fc23/x86_64/squid-3.5.10-2.fc23.x86_64.rpm

2) # getenforce 
Enforcing

3) # cat /etc/fedora-release 
Fedora release 23 (Twenty Three)

4) # systemctl start squid

5) # systemctl status squid
● squid.service - Squid caching proxy
   Loaded: loaded (/usr/lib/systemd/system/squid.service; disabled; vendor preset: disabled)
   Active: active (running) since Thu 2016-04-07 05:56:30 EDT; 23min ago
  Process: 3750 ExecStart=/usr/sbin/squid $SQUID_OPTS -f $SQUID_CONF (code=exited, status=0/SUCCESS)
  Process: 3742 ExecStartPre=/usr/libexec/squid/cache_swap.sh (code=exited, status=0/SUCCESS)
 Main PID: 3752 (squid)
   CGroup: /system.slice/squid.service
           ├─3752 /usr/sbin/squid -f /etc/squid/squid.conf
           ├─3754 (squid-1) -f /etc/squid/squid.conf
           └─3755 (logfile-daemon) /var/log/squid/access.log

Apr 07 05:56:29 HOSTNAME systemd[1]: Starting Squid caching proxy...
Apr 07 05:56:30 HOSTNAME squid[3752]: Squid Parent: will start 1 kids
Apr 07 05:56:30 HOSTNAME squid[3752]: Squid Parent: (squid-1) process 3754 started
Apr 07 05:56:30 HOSTNAME systemd[1]: Started Squid caching proxy.

I used default configuration file and fresh install of F23.

Note: I also tried the configuration, you have attached and I haven't experienced any problems.

I am using squid with ssl_crtd which is generating the following SELinux errors,

Apr 09 16:42:37 proxy1 audit[2876]: AVC avc:  denied  { read } for  pid=2876 comm="ssl_crtd" name="index.txt" dev="xvda3" ino=17256413 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
Apr 09 16:43:44 proxy1 audit[3024]: AVC avc:  denied  { open } for  pid=3024 comm="ssl_crtd" path="/var/lib/ssl_db/index.txt" dev="xvda3" ino=17256413 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
Apr 09 16:44:40 proxy1 audit[3153]: AVC avc:  denied  { getattr } for  pid=3153 comm="ssl_crtd" path="/var/lib/ssl_db/index.txt" dev="xvda3" ino=17256413 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
Apr 09 16:46:48 proxy1 audit[3264]: AVC avc:  denied  { lock } for  pid=3264 comm="ssl_crtd" path="/var/lib/ssl_db/index.txt" dev="xvda3" ino=17256413 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
Apr 09 16:47:26 proxy1 audit[3403]: AVC avc:  denied  { write } for  pid=3403 comm="ssl_crtd" name="certs" dev="xvda3" ino=25175635 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir permissive=0
Apr 09 16:48:41 proxy1 audit[3528]: AVC avc:  denied  { add_name } for  pid=3528 comm="ssl_crtd" name="1CD3C2FD3B0DF41881036E5ABC44206BB583B6F0.pem" scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir permissive=0
Apr 09 16:49:22 proxy1 audit[3665]: AVC avc:  denied  { create } for  pid=3665 comm="ssl_crtd" name="6D4E62214691FF0826A9ECBCD8DE708EF1DFC632.pem" scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
Apr 09 17:01:07 proxy1 audit[812]: AVC avc:  denied  { remove_name } for  pid=812 comm="ssl_crtd" name="0F29746F4650BD5CB807793C952999065898AAC6.pem" dev="xvda3" ino=25175593 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir permissive=0
Apr 09 17:02:58 proxy1 audit[2164]: AVC avc:  denied  { unlink } for  pid=2164 comm="ssl_crtd" name="0F29746F4650BD5CB807793C952999065898AAC6.pem" dev="xvda3" ino=25175593 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0

I solved by interatively applying SELinux policy updates, ultimately resulting in,

module ssl_crtdlocal 1.0;
require {
	type squid_t;
	type var_lib_t;
	class dir { add_name remove_name write };
	class file { create getattr lock open read unlink write };
}
#============= squid_t ==============
allow squid_t var_lib_t:dir { add_name remove_name write };
allow squid_t var_lib_t:file { create getattr lock open read unlink write };

The relevant squid.conf entry is,

sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB

The errors occur on current fc24 and rawhide. They were also in fc23 however haven't been testing with that for a few months.

Since you couldn't reproduce the issue, I tried to. I installed squid on a dnf updated fedora 23 cloud machine by running:

sudo dnf update -y
sudo dnf install squid -y

$ cat /etc/redhat-release
Fedora release 23 (Twenty Three)

sudo systemctl start squid
sudo systemctl stop squid
sudo systemctl restart squid

I received squid-3.5.9-7.fc23.x86_64. Confirmed with:

$ rpm -qa | grep squid
squid-3.5.9-7.fc23.x86_64

I did not receive any denials. SELinux is Enforcing as told by getenforce. I was not able to reproduce the issue I saw in my Vagrant development environment.

The other environment I was using did have certificates configured. My current thinking is that Comment 6 is likely what I was experiencing. Even though normal squid usage has no problem, I think there is something about that environment which causes the SELinux denial.

I tried the squid config file from the vagrant environment and it did not produce the SELinux denial either. Maybe a cert configuration? I'm not sure if we are still affected by this in the other environment because we carry the workaround now[0].

[0]: https://github.com/pulp/pulp/commit/df7e5c5b533ae6e3e2d962a3df47ed027d3df22c#diff-55c0ad69105815228aac56aa704fa9c2R94

Since there is no reproducer, I'm closing this bug as INSUFFICIENT_DATA. If you experience this bug again, feel free to reopen it.

On fedora 23 I can again reproduce the error.

Using the default install via yum and adding the squid.conf from Brian in the first comment in http://bugs.squid-cache.org/show_bug.cgi?id=4444.

Selinux stops the ssl_crtd squid certificate database generator and worker to function properly.
There is no rule defined for ssl_crtd, and no access context listed.

[root@mx1 gdata]# semanage fcontext --list | grep crtd
results in no details.

[root@mx1 gdata]# semanage fcontext --list | grep squid
/dev/shm/squid-*                                   regular file       system_u:object_r:squid_tmpfs_t:s0 
/etc/lightsquid(/.*)?                              all files          system_u:object_r:squid_conf_t:s0 
/etc/rc\.d/init\.d/squid                           regular file       system_u:object_r:squid_initrc_exec_t:s0 
/etc/squid(/.*)?                                   all files          system_u:object_r:squid_conf_t:s0 
/usr/lib/squid/cachemgr\.cgi                       regular file       system_u:object_r:squid_script_exec_t:s0 
/usr/libexec/squid/cache_swap\.sh                  regular file       system_u:object_r:squid_exec_t:s0 
/usr/sbin/lightparser.pl                           regular file       system_u:object_r:squid_cron_exec_t:s0 
/usr/sbin/squid                                    regular file       system_u:object_r:squid_exec_t:s0 
/usr/share/lightsquid/cgi(/.*)?                    all files          system_u:object_r:squid_script_exec_t:s0 
/usr/share/munin/plugins/squid_.*                  regular file       system_u:object_r:services_munin_plugin_exec_t:s0 
/usr/share/squid(/.*)?                             all files          system_u:object_r:squid_conf_t:s0 
/var/cache/squid(/.*)?                             all files          system_u:object_r:squid_cache_t:s0 
/var/lightsquid(/.*)?                              all files          system_u:object_r:squid_cache_t:s0 
/var/log/squid(/.*)?                               all files          system_u:object_r:squid_log_t:s0 
/var/log/squidGuard(/.*)?                          all files          system_u:object_r:squid_log_t:s0 
/var/run/squid.*                                   all files          system_u:object_r:squid_var_run_t:s0 
/var/spool/squid(/.*)?                             all files          system_u:object_r:squid_cache_t:s0 
/var/squidGuard(/.*)?                              all files          system_u:object_r:squid_cache_t:s0 
[root@mx1 gdata]# semanage fcontext --list | grep ssl_crtd


running squid with the ssl_crtd helper processes fails.
cat /var/log/squid/cache.log

2016/08/24 16:06:08 kid1| Adding domain mail17.qa.local from /etc/resolv.conf
2016/08/24 16:06:08 kid1| Adding domain qa.local from /etc/resolv.conf
2016/08/24 16:06:08 kid1| Adding domain gdata.de from /etc/resolv.conf
2016/08/24 16:06:08 kid1| Adding nameserver 10.28.8.2 from /etc/resolv.conf
2016/08/24 16:06:08 kid1| Adding nameserver 10.28.8.3 from /etc/resolv.conf
2016/08/24 16:06:08 kid1| helperOpenServers: Starting 5/5 'ssl_crtd' processes
(ssl_crtd): Uninitialized SSL certificate database directory: /var/lib/ssl_db. To initialize, run "ssl_crtd -c -s /var/lib/ssl_db".
(ssl_crtd): Uninitialized SSL certificate database directory: /var/lib/ssl_db. To initialize, run "ssl_crtd -c -s /var/lib/ssl_db".
(ssl_crtd): Uninitialized SSL certificate database directory: /var/lib/ssl_db. To initialize, run "ssl_crtd -c -s /var/lib/ssl_db".
2016/08/24 16:06:08 kid1| Logfile: opening log daemon:/var/log/squid/access.log
2016/08/24 16:06:08 kid1| Logfile Daemon: opening log /var/log/squid/access.log
(ssl_crtd): Uninitialized SSL certificate database directory: /var/lib/ssl_db. To initialize, run "ssl_crtd -c -s /var/lib/ssl_db".
2016/08/24 16:06:08 kid1| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec
2016/08/24 16:06:08 kid1| Store logging disabled


Setting the selinux to enforcing=0 makes the ssl_crtd work again
The following entries are found in /var/log/audit/audit.log

type=USER_AVC msg=audit(1472043853.010:357): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received setenforce notice (enforcing=0)  exe="/usr/lib/systemd/systemd" sauid=0 hostname
=? addr=? terminal=?' 
type=SERVICE_START msg=audit(1472043853.076:358): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=squid comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=
success' 
type=AVC msg=audit(1472043853.120:359): avc:  denied  { read } for  pid=1800 comm="ssl_crtd" name="index.txt" dev="dm-0" ino=47945 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=f
ile permissive=1 
type=AVC msg=audit(1472043853.120:360): avc:  denied  { open } for  pid=1800 comm="ssl_crtd" path="/var/lib/ssl_db/index.txt" dev="dm-0" ino=47945 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_l
ib_t:s0 tclass=file permissive=1 
type=AVC msg=audit(1472043853.120:361): avc:  denied  { getattr } for  pid=1800 comm="ssl_crtd" path="/var/lib/ssl_db/index.txt" dev="dm-0" ino=47945 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:va
r_lib_t:s0 tclass=file permissive=1 
type=AVC msg=audit(1472044502.167:362): avc:  denied  { create } for  pid=1828 comm="local" name="Maildir" scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir permissive=1 
type=AVC msg=audit(1472044502.167:363): avc:  denied  { create } for  pid=1828 comm="local"

OK, I reopened this bug, since I got an acknowledgement from selinux team, that this is the problem of selinux-policy package and will be fixed in near future. 

So please, be patient and let's wait for selinux team.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.