Hide Forgot
Description of problem: Spamassassin rules are periodcally updated by sa-update.cron script. I added proxy configuration to /etc/sysconfig/sa-update: echo 'export http_proxy=http://10.10.18.6:8080' >> /etc/sysconfig/sa-update Unfortunately, SELinux blocks sa-update access through proxy: # cat /var/log/sa-update.log Update available for channel sought.rules.yerp.org: -1 -> 3402014020421 http: (curl) GET http://yerp.org/rules/MIRRORED.BY, FAILED, status: 1792 error: no mirror data available for channel sought.rules.yerp.org channel: MIRRORED.BY file contents were missing, channel failed Update available for channel updates.spamassassin.org: -1 -> 1728924 http: (curl) GET http://spamassassin.apache.org/updates/MIRRORED.BY, FAILED, status: 1792 error: no mirror data available for channel updates.spamassassin.org channel: MIRRORED.BY file contents were missing, channel failed Update failed, exiting with code 4 08-Feb-2016 10:15:03: SpamAssassin: Update available, but download or extract failed Audit messages: type=AVC msg=audit(1454922903.530:737): avc: denied { name_connect } for pid=3744 comm="curl" dest=8080 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1454922903.530:737): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7ffc967ae450 a2=10 a3=7ffc967ae070 items=0 ppid=3740 pid=3744 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=50 comm="curl" exe="/usr/bin/curl" subj=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 key=(null) I generated and applied local policy to allow this access: # grep spamd_update_t /var/log/audit/audit.log | audit2allow -M sa-update_proxy ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i sa-update_proxy.pp # semodule -i sa-update_proxy.pp # cat sa-update_proxy.te module sa-update_proxy 1.0; require { type spamd_update_t; type http_cache_port_t; class tcp_socket name_connect; } #============= spamd_update_t ============== allow spamd_update_t http_cache_port_t:tcp_socket name_connect; After that sa-update works through proxy: # cat /var/log/sa-update.log Update available for channel sought.rules.yerp.org: -1 -> 3402014020421 http: (curl) GET http://yerp.org/rules/MIRRORED.BY, success http: (curl) GET http://rules.yerp.org.s3.amazonaws.com/rules/stage/3402014020421.tar.gz, success http: (curl) GET http://rules.yerp.org.s3.amazonaws.com/rules/stage/3402014020421.tar.gz.sha1, success http: (curl) GET http://rules.yerp.org.s3.amazonaws.com/rules/stage/3402014020421.tar.gz.asc, success Update available for channel updates.spamassassin.org: -1 -> 1728924 http: (curl) GET http://spamassassin.apache.org/updates/MIRRORED.BY, success http: (curl) GET http://sa-update.secnap.net/1728924.tar.gz, success http: (curl) GET http://sa-update.secnap.net/1728924.tar.gz.sha1, success http: (curl) GET http://sa-update.secnap.net/1728924.tar.gz.asc, success Update was available, and was downloaded and installed successfully 08-Feb-2016 10:22:10: SpamAssassin: Update processed successfully Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-60.el7.noarch selinux-policy-3.13.1-60.el7.noarch How reproducible: Adding proxy configuration to sa-update Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Similar scenario which uses the squid also generates SELinux denials: ---- type=SOCKADDR msg=audit(02/08/2016 15:26:59.385:2102) : saddr=inet host:127.0.0.1 serv:3128 type=SYSCALL msg=audit(02/08/2016 15:26:59.385:2102) : arch=x86_64 syscall=connect success=no exit=-13(Permission denied) a0=0x3 a1=0x7ffd27bd73d0 a2=0x10 a3=0x7ffd27bd6ff0 items=0 ppid=16110 pid=16117 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=207 comm=curl exe=/usr/bin/curl subj=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(02/08/2016 15:26:59.385:2102) : avc: denied { name_connect } for pid=16117 comm=curl dest=3128 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_port_t:s0 tclass=tcp_socket ---- system_u:system_r:spamd_update_t:s0-s0:c0.c1023 root 16726 15493 0 15:30 ? 00:00:00 /usr/bin/perl -T -w /usr/bin/sa-update -v --allowplugins --refreshmirrors --channel sought.rules.yerp.org --channel updates.spamassassin.org --gpgkey 6C6191E3 --gpgkey 5244EC45 # grep http_proxy /etc/sysconfig/sa-update export http_proxy=http://127.0.0.1:3128/ # netstat -tupan | grep 3128 tcp6 0 0 :::3128 :::* LISTEN 9090/(squid-1) #
Maybe we should create new boolean here, because I believe there is not a default port to connect. Wha do you think, Milos?
I'm fine with that.
We are affected by this as well. It's been two months. Has the update been released yet? Also, I would argue that toggling whether individual roles can make outbound http/https connections through a proxy doesn't make sense. Whether an outbound proxy is in use is almost always implemented as network/firewall policy, and thus is going to be a system-wide setting. Accordingly, I think a better long-term fix for this issue would be to create a boolean to indicate whether the network policy is that the host makes http[s] connections directly, or through a proxy. If the latter, then corenet_tcp_connect_http_port() should permit not just 80/443, but all of the ports that corenet_tcp_connect_http_cache_port() permits. This will obviate the need to add booleans to every potential role that makes outbound http/https connections. (Perhaps that is what you already implemented, but I don't know, because there aren't any details on what the new boolean is or what it will toggle.)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2283.html