Hi, I've setup a transparent HTTP+HTTPS proxy on my server running CentOS 7, using Squid. Here's my configuration file. --8<---------------------------------------------------------------- # /etc/squid/squid.conf # D?finitions acl localnet src 192.168.2.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # R?gles d'acc?s http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localnet http_access allow localhost http_access deny all # Ports du proxy http_port 3130 http_port 3128 intercept https_port 3129 intercept ssl-bump \ cert=/etc/squid/ssl_cert/nestor.microlinux.lan.pem \ generate-host-certificates=on dynamic_cert_mem_cache_size=4MB # Emplacement de ssl_crtd et du cache des certificats TLS sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslcrtd_children 8 startup=1 idle=1 # SSL-Bump acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump all # Taille du cache dans la RAM cache_mem 2048 MB # Emplacement et taille du cache sur le disque # cache_dir ufs /var/spool/squid 100 16 256 # Vidage syst?me coredump_dir /var/spool/squid # Dur?e de vie des fichiers sans date d'expiration refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 --8<---------------------------------------------------------------- First, I tested the configuration in permissive mode, where it works perfectly. After running it a while, I get the following SELinux alert. # sealert -a /var/log/audit/audit.log ***** Plugin catchall (17.1 confidence) suggests ***** If you believe that ssl_crtd should be allowed read access on the index.txt file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'ssl_crtd' --raw | audit2allow -M my-sslcrtd # semodule -i my-sslcrtd.pp Unfortunately the suggested solution doesn't work, because the problem reappears, and I get all sorts of errors in /var/log/squid/cache.log, all due to ssl_crtd not being able to access stuff under /var/lib/ssl_db. Any idea how I can solve this problem permanently ? Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32
The ausearch is only identifying issues that there are logs for at that time. Best to create a file context for that path permanantly. Theres an example of how to do this in the selinux man pages. Typing on my phone im tryinf to remember the command that the example in its man page. Semanage fcontext is what you are looking for followed by a restorecon on the path you added. Regards peter Sent with AquaMail for Android http://www.aqua-mail.com On 9 March 2018 13:18:45 "Nicolas Kovacs" <info at microlinux.fr> wrote:> Hi, > > I've setup a transparent HTTP+HTTPS proxy on my server running CentOS 7, > using Squid. Here's my configuration file. > > --8<---------------------------------------------------------------- > # /etc/squid/squid.conf > > > > # D?finitions > > acl localnet src 192.168.2.0/24 > > acl SSL_ports port 443 > > acl Safe_ports port 80 # http > > acl Safe_ports port 21 # ftp > > acl Safe_ports port 443 # https > > acl Safe_ports port 70 # gopher > > acl Safe_ports port 210 # wais > > acl Safe_ports port 1025-65535 # unregistered ports > > acl Safe_ports port 280 # http-mgmt > acl Safe_ports port 488 # gss-http > acl Safe_ports port 591 # filemaker > acl Safe_ports port 777 # multiling http > acl CONNECT method CONNECT > > # R?gles d'acc?s > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports > http_access allow localhost manager > http_access deny manager > http_access allow localnet > http_access allow localhost > http_access deny all > > # Ports du proxy > http_port 3130 > http_port 3128 intercept > https_port 3129 intercept ssl-bump \ > cert=/etc/squid/ssl_cert/nestor.microlinux.lan.pem \ > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > > # Emplacement de ssl_crtd et du cache des certificats TLS > sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB > sslcrtd_children 8 startup=1 idle=1 > > # SSL-Bump > acl step1 at_step SslBump1 > ssl_bump peek step1 > ssl_bump bump all > > # Taille du cache dans la RAM > cache_mem 2048 MB > > # Emplacement et taille du cache sur le disque > # cache_dir ufs /var/spool/squid 100 16 256 > > # Vidage syst?me > coredump_dir /var/spool/squid > > # Dur?e de vie des fichiers sans date d'expiration > refresh_pattern ^ftp: 1440 20% 10080 > refresh_pattern ^gopher: 1440 0% 1440 > refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 > refresh_pattern . 0 20% 4320 > --8<---------------------------------------------------------------- > > First, I tested the configuration in permissive mode, where it works > perfectly. After running it a while, I get the following SELinux alert. > > # sealert -a /var/log/audit/audit.log > ***** Plugin catchall (17.1 confidence) suggests ***** > If you believe that ssl_crtd should be allowed read access on the > index.txt file by default. Then you should report this as a bug. You can > generate a local policy module to allow this access. Do allow this > access for now by executing: > # ausearch -c 'ssl_crtd' --raw | audit2allow -M my-sslcrtd > # semodule -i my-sslcrtd.pp > > Unfortunately the suggested solution doesn't work, because the problem > reappears, and I get all sorts of errors in /var/log/squid/cache.log, > all due to ssl_crtd not being able to access stuff under /var/lib/ssl_db. > > Any idea how I can solve this problem permanently ? > > Cheers, > > Niki > > -- > Microlinux - Solutions informatiques durables > 7, place de l'?glise - 30730 Montpezat > Site : https://www.microlinux.fr > Blog : https://blog.microlinux.fr > Mail : info at microlinux.fr > T?l. : 04 66 63 10 32 > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos
On 03/09/2018 05:18 AM, Nicolas Kovacs wrote:> Do allow this > access for now by executing: > # ausearch -c 'ssl_crtd' --raw | audit2allow -M my-sslcrtd > # semodule -i my-sslcrtd.pp > > Unfortunately the suggested solution doesn't workStart by running "ausearch -c 'ssl_crtd' --raw" by itself.? Try to determine whether or not all of the affected files are mentioned in that output. Typically, to generate a complete policy, you'll need to run in permissive mode while you operate the system, so that all of the things that you want to allow are recorded.? Many services that need a new policy will generate more than one AVC denial, and in enforcing mode they'll terminate or at least cease processing the labeled resources that they need after the first denial.? In permissive mode, you should get a better list of exceptions that are required, because AVCs are recorded, but the application isn't actually denied permission to those resources. When your logs are complete, remove the old module and generate a new one according to the directions from sealert.
Le 10/03/2018 ? 18:18, Gordon Messmer a ?crit?:> Start by running "ausearch -c 'ssl_crtd' --raw" by itself.? Try to > determine whether or not all of the affected files are mentioned in that > output. > > Typically, to generate a complete policy, you'll need to run in > permissive mode while you operate the system, so that all of the things > that you want to allow are recorded.? Many services that need a new > policy will generate more than one AVC denial, and in enforcing mode > they'll terminate or at least cease processing the labeled resources > that they need after the first denial.? In permissive mode, you should > get a better list of exceptions that are required, because AVCs are > recorded, but the application isn't actually denied permission to those > resources. > > When your logs are complete, remove the old module and generate a new > one according to the directions from sealert.OK, I found the solution. This is actually a bug in Squid's default SELinux policy, but it can be corrected manually. https://blog.microlinux.fr/squid-https-centos/#configuration Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32