Bug 399001 - openvpn being denied write access to /etc/openvpn
openvpn being denied write access to /etc/openvpn
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openvpn (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Steven Pritchard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-25 21:33 EST by Yves Perrenoud
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-26 12:06:27 EST
Type: ---
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 Yves Perrenoud 2007-11-25 21:33:36 EST
Description of problem:

openvpn needs to write to /etc/openvpn, specifically it needs to create and
write to /etc/openvpn/ipp.txt and /etc/openvpn/openvpn-status.log. It's
currently being denied that access. If I set it to permissive, I get these AVC
entries:

audit(1196043477.470:48): avc:  denied  { write } for  pid=3540 comm="openvpn"
name="openvpn" dev=sda1 ino=773278 scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=dir
audit(1196043477.470:49): avc:  denied  { add_name } for  pid=3540
comm="openvpn" name="openvpn-status.log" scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=dir
audit(1196043477.470:50): avc:  denied  { create } for  pid=3540 comm="openvpn"
name="openvpn-status.log" scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=file
audit(1196043477.471:51): avc:  denied  { write } for  pid=3540 comm="openvpn"
name="openvpn-status.log" dev=sda1 ino=770085
scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=file


Version-Release number of selected component (if applicable):

selinux-policy-targeted-3.0.8-56.fc8
Comment 1 Yves Perrenoud 2007-11-25 21:39:57 EST
Here's the AVC for ipp.txt:

audit(1196044088.763:58): avc:  denied  { write } for  pid=3551 comm="openvpn"
name="ipp.txt" dev=sda1 ino=770086 scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:object_r:openvpn_etc_t:s0 tclass=file
Comment 2 Daniel Walsh 2007-11-26 10:51:47 EST
This is a bug in openvpn.  It should not be storing data under /etc and it
should not be writing log files in /etc.  It should use /var/log/openvpn for log
files and /var/lib/openvpn or /var/run/openvpn for ipp.txt depending on whether
this is persistant across reboots.

/etc should be treated as read/only by all apps.  

If you want to add these rules to SELinux you can use audit2allow.

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

Reassigning to openvpn.  When this app is fixed to write to the correct
directories I will update SELinux to allow the access.
Comment 3 Steven Pritchard 2007-11-26 12:06:27 EST
The only reason openvpn would write to these directories is if the user
configures it to.  I have bug #196564 open to remind me to go through the
upstream sample config files to change anything obviously wrong like this, but
it is still up to the user to configure openvpn properly.
Comment 4 Yves Perrenoud 2007-11-26 16:04:28 EST
In the openvpn config I have the following entries:

ifconfig-pool-persist ipp.txt
status openvpn-status.log

Thus it's openvpn that's deciding to default the directory for those two to
/etc/openvpn. This syntax comes from the sample configs. If possible, it might
be a good idea to make openvpn default those two files to /var/log and
/var/run/openvpn respectively when no absolute path is provided.

There should probably also be a preuninstall hook in the RPM to cleanup the
ipp.txt file or else the /var/run/openvpn directory won't be removed.

I've hard coded /var/log/openvpn-status.log and /var/run/openvpn/ipp.txt in the
config file and it hasn't tripped selinux, so that's working for now.

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