Bug 1305469
Summary: | SElinux is preventing cron Spamassassin update (sa-update.cron) through proxy | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Pawel Bien <pawel.bien> |
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.2 | CC: | lvrabec, mgrepl, mmalik, plautrba, pvrabec, ralston, rsahoo, ssekidde |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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-04 02:42:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pawel Bien
2016-02-08 10:41:28 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) # 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 |