Bug 1008302 - SELinux is preventing /usr/sbin/openvpn from 'write' accesses on the file /etc/openvpn/openvpn-status.log.
SELinux is preventing /usr/sbin/openvpn from 'write' accesses on the file /et...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
18
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
abrt_hash:b68939b732debbc20668a8b41c8...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-16 02:11 EDT by SimonHP
Modified: 2013-09-16 08:24 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-16 08:07:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: C:\nppdf32Log\debuglog.txt (54 bytes, text/plain)
2013-09-16 02:11 EDT, SimonHP
no flags Details

  None (edit)
Description SimonHP 2013-09-16 02:11:06 EDT
Description of problem:
Whenever updates are applied (Fedora 18 - but also occurred in previous releases), SELinux seems to revert to previous behaviour and stop openVPN from writing to its own log file (openvpn-status.log). This prevents OpenVPN service from starting and thereby prevents OpenVPN from being available. If you only have access to a remote machine via openVPN, this would effectively lock out admin of the machine.

The same behaviour also appears to impact httpd after an update - so it would appear to be caused by SELinux rather than by OpenVPN.

the suggested fixes below do work to fix the issue:

# grep openvpn /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

SELinux is preventing /usr/sbin/openvpn from 'write' accesses on the file /etc/openvpn/openvpn-status.log.

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

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

Additional Information:
Source Context                system_u:system_r:openvpn_t:s0
Target Context                system_u:object_r:openvpn_etc_t:s0
Target Objects                /etc/openvpn/openvpn-status.log [ file ]
Source                        openvpn
Source Path                   /usr/sbin/openvpn
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           openvpn-2.3.2-1.fc18.i686
Target RPM Packages           
Policy RPM                    selinux-policy-3.11.1-100.fc18.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.10.10-100.fc18.i686.PAE #1 SMP
                              Thu Aug 29 20:27:06 UTC 2013 i686 i686
Alert Count                   1
First Seen                    2013-09-16 17:57:59 NZST
Last Seen                     2013-09-16 17:57:59 NZST
Local ID                      2f3db2dc-8ba2-418d-b678-6521d6f1cc58

Raw Audit Messages
type=AVC msg=audit(1379311079.852:3900): avc:  denied  { write } for  pid=21118 comm="openvpn" name="openvpn-status.log" dev="dm-1" ino=5245760 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=file


type=SYSCALL msg=audit(1379311079.852:3900): arch=i386 syscall=access success=no exit=EACCES a0=b8ec512c a1=2 a2=b7718a0c a3=0 items=0 ppid=1 pid=21118 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null)

Hash: openvpn,openvpn_t,openvpn_etc_t,file,write

audit2allow

#============= openvpn_t ==============
allow openvpn_t openvpn_etc_t:file write;

audit2allow -R
require {
	type openvpn_t;
	type openvpn_etc_t;
	class file write;
}

#============= openvpn_t ==============
allow openvpn_t openvpn_etc_t:file write;


Additional info:
reporter:       libreport-2.1.6
hashmarkername: setroubleshoot
kernel:         3.10.10-100.fc18.i686.PAE
type:           libreport

Potential duplicate: bug 1002240
Comment 1 SimonHP 2013-09-16 02:11:11 EDT
Created attachment 798106 [details]
File: C:\nppdf32Log\debuglog.txt
Comment 2 Lukas Vrabec 2013-09-16 05:23:56 EDT
Hi Simon, 

Could you post here your status path in your config file? Because file "openvpn-status.log" is not in right directory. It should by located in "/var/log".
Comment 3 SimonHP 2013-09-16 07:50:05 EDT
Hi Lucas.

You are correct, the status line is:

status /etc/openvpn/openvpn-status.log

I will change as suggested to /var/log/openvpn/openvpn-status.log

Thank you, I hope this will fix the issue.

Regards
Simon
Comment 4 Lukas Vrabec 2013-09-16 08:03:45 EDT
I would suggest you to put openvpn-status.log just into directory "/var/log/". 
example: 
 status /var/log/openvpn-status.log

Because in openvpn policy is path to openvpn-status.log:
 
/var/log/openvpn-status\.log.*  --     gen_context(system_u:object_r:openvpn_status_t,s0)
Comment 5 Miroslav Grepl 2013-09-16 08:07:28 EDT
Where does

status /etc/openvpn/openvpn-status.log

come from? Is this a default setup?
Comment 6 SimonHP 2013-09-16 08:24:59 EDT
Hi Lukas,

Thanks for the suggestion. Will do so. Should the ipp.txt file also be in the same location.

Hi Miroslav,

I think the default server file came from: http://openvpn.net/index.php/open-source/documentation/howto.html

The status line does not have a path in that file. I cannot remember the exact details, however I seem to remember I had an issue getting it to run properly under systemd (which I did resolve) and I may have added the path to troubleshoot. When I got it working, I left it as it was.

Thanks for your assistance
Regards
Simon

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