RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1305469 - SElinux is preventing cron Spamassassin update (sa-update.cron) through proxy
Summary: SElinux is preventing cron Spamassassin update (sa-update.cron) through proxy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.2
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-08 10:41 UTC by Pawel Bien
Modified: 2020-02-14 17:40 UTC (History)
8 users (show)

Fixed In Version: selinux-policy-3.13.1-81.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 02:42:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2283 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2016-11-03 13:36:25 UTC

Description Pawel Bien 2016-02-08 10:41:28 UTC
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 14:35:15 UTC
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 15:05:28 UTC
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 16:00:00 UTC
I'm fine with that.

Comment 8 James Ralston 2016-09-28 16:00:05 UTC
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-04 02:42:21 UTC
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.