Bug 1305469 - SElinux is preventing cron Spamassassin update (sa-update.cron) through proxy
SElinux is preventing cron Spamassassin update (sa-update.cron) through proxy
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.2
All Linux
high Severity high
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-08 05:41 EST by Pawel Bien
Modified: 2016-12-29 04:52 EST (History)
8 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-81.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 22:42:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pawel Bien 2016-02-08 05:41:28 EST
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:
Comment 2 Milos Malik 2016-02-08 09:35:15 EST
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)      
#
Comment 3 Lukas Vrabec 2016-06-20 11:05:28 EDT
Maybe we should create new boolean here, because I believe there is not a default port to connect. Wha do you think, Milos?
Comment 4 Milos Malik 2016-06-20 12:00:00 EDT
I'm fine with that.
Comment 8 James Ralston 2016-09-28 12:00:05 EDT
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.)
Comment 11 errata-xmlrpc 2016-11-03 22:42:21 EDT
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

Note You need to log in before you can comment on or make changes to this bug.