Bug 1118420 - SELinux is preventing /usr/sbin/httpd from 'search' accesses on the directory /etc/openvpn.
Summary: SELinux is preventing /usr/sbin/httpd from 'search' accesses on the directory...
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 21
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Jan Kaluža
QA Contact: Fedora Extras Quality Assurance
Whiteboard: abrt_hash:f8db30ea2d9a96b911d2c148424...
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-10 16:35 UTC by Jared Smith
Modified: 2014-07-30 12:16 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-07-30 12:16:16 UTC
Type: ---

Attachments (Terms of Use)

Description Jared Smith 2014-07-10 16:35:28 UTC
Description of problem:
SELinux is preventing /usr/sbin/httpd from 'search' accesses on the directory /etc/openvpn.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that httpd should be allowed search access on the openvpn directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                system_u:object_r:openvpn_etc_t:s0
Target Objects                /etc/openvpn [ dir ]
Source                        httpd
Source Path                   /usr/sbin/httpd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           httpd-2.4.9-8.fc21.x86_64
Target RPM Packages           openvpn-2.3.4-2.fc21.x86_64
Policy RPM                    selinux-policy-3.13.1-63.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.16.0-0.rc4.git2.1.fc21.x86_64 #1
                              SMP Wed Jul 9 17:14:09 UTC 2014 x86_64 x86_64
Alert Count                   29
First Seen                    2014-05-31 10:33:04 EDT
Last Seen                     2014-07-10 12:33:50 EDT
Local ID                      d02cce32-d1bf-4cf1-85d0-6937b0b74921

Raw Audit Messages
type=AVC msg=audit(1405010030.584:576): avc:  denied  { search } for  pid=7067 comm="httpd" name="openvpn" dev="dm-2" ino=1840816 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=dir permissive=0

type=SYSCALL msg=audit(1405010030.584:576): arch=x86_64 syscall=stat success=no exit=EACCES a0=7f3622d552a0 a1=7fff8c011650 a2=7fff8c011650 a3=3a items=0 ppid=7066 pid=7067 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)

Hash: httpd,httpd_t,openvpn_etc_t,dir,search

Version-Release number of selected component:

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.16.0-0.rc4.git2.1.fc21.x86_64
type:           libreport

Potential duplicate: bug 817333

Comment 1 Lukas Vrabec 2014-07-14 08:52:44 UTC
What were you doing when this happened? 

Why is apache search through openvpn config?

Comment 2 Jared Smith 2014-07-14 18:23:38 UTC
I'm not really sure -- the only thing I remember doing is restarting Apache after adding a new virtual host.

Comment 3 Miroslav Grepl 2014-07-16 11:04:17 UTC
any idea what could it cause?

Comment 4 Daniel Walsh 2014-07-30 11:25:59 UTC
We have had multiple bugs over the years where httpd randomly searches directories.  I am pretty sure this can be safely ignored.

Comment 5 Joe Orton 2014-07-30 12:16:16 UTC
I would be more than a little paranoid about seeing httpd scanning /etc/openvpn.  Possibilities:

1) You've been hacked.
2) Some weird httpd system management script is scanning /etc?
3) There is a path through the resolver/network stack/... which leads to httpd trying to access /etc/openvpn "legitimately".  I can't imagine what.
4) Something else.

Certainly we should keep the audit errors for these, they are weird & surprising.

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