Proxy - squid-local.te (SELinux module)

Proxy Solution · Config document · referenced from SELinux and client trust

A local SELinux type-enforcement module for Squid's ssl_crtd helper. On RHEL 7.5 Squid refused to start with the message (ssl_crtd): Uninitialized SSL certificate database directory: /var/lib/ssl_db although the database had been initialised, because SELinux stopped the helper, which runs in the squid_t domain, from writing into /var/lib/ssl_db, a directory labelled var_lib_t. The file is what audit2allow generated from the collected audit messages; the commands that produced and installed it are in the Article.

The file

module squid-local 1.0;

require {
        type squid_t;
        type var_lib_t;
        class file { create getattr lock open read write };
        class dir { add_name write };
}

#============= squid_t ==============
allow squid_t var_lib_t:dir { add_name write };

#!!!! WARNING: 'var_lib_t' is a base type.
allow squid_t var_lib_t:file { create getattr lock open read write };

The file is as audit2allow printed it, including its own #============= and #!!!! WARNING comment lines; nothing was added or edited.

What the lines mean

The module was not needed at all, as a check against the policy package of RHEL 7.5 shows (next section): the policy already labelled /var/lib/ssl_db as squid_cache_t, and the directory only carried var_lib_t because ssl_crtd -c created it from a root shell and nothing relabelled it. restorecon -Rv /var/lib/ssl_db would have been the whole fix. The module stays here as it was built and loaded; see SELinux and client trust.

Checked against selinux-policy, RHEL 7.5 to RHEL 10

The label was there before the module was. The warning audit2allow wrote into the file was the hint, and ls -Z /var/lib/ssl_db next to matchpathcon /var/lib/ssl_db would have shown the difference between the label the directory had and the one the policy wanted.