Bug 1480741

Summary:	selinux policy lacks svnserve_log_t, which breaks svnserve logging
Product:	Red Hat Enterprise Linux 7	Reporter:	James Ralston <ralston>
Component:	selinux-policy	Assignee:	Lukas Vrabec <lvrabec>
Status:	CLOSED ERRATA	QA Contact:	Milos Malik <mmalik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.4	CC:	lvrabec, mgrepl, mmalik, plautrba, pvrabec, ssekidde, zpytela
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	selinux-policy-3.13.1-175.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-10 12:38: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 James Ralston 2017-08-11 19:19:22 UTC

Description of problem:

SELinux blocks attempts to have svnserve log to /var/log/svnserve/svnserve.log, because there is no svnserve_log_t type (or rules to apply that label to the filesystem), and the targeted policy does not permit svnserve to write to files with the generic var_log_t type.

For now, I have worked around this issue with:

$ semanage fcontext -a -t svnserve_var_run_t '/var/log/svnserve(/.*)?'
$ restorecon -FRv /var/log

But this is a kluge, and only works because svnserve_t is permitted to write to svnserve_var_run_t. There should be a separate svnserve_log_t file context for '/var/log/svnserve(/.*)?', and svnserve_t should be able to write to it.

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

selinux-policy-targeted-3.13.1-102.el7_3.4.noarch

How reproducible:

Add "--log-file /var/log/svnserve/svnserve.log" to OPTIONS in /etc/sysconfig/svnserve and restart svnserve.

Actual results:

svnserve will fail to start, emitting the following error:

svnserve: svn: E000013: Can't open file '/var/log/svnserve/svnserve.log': Permission denied

Expected results:

svnserve should start, opening the log file.

Comment 2 Milos Malik 2017-08-14 09:26:23 UTC

You're right, James.

# rpm -qa selinux\*
selinux-policy-targeted-3.13.1-166.el7.noarch
selinux-policy-3.13.1-166.el7.noarch
selinux-policy-mls-3.13.1-166.el7.noarch
selinux-policy-devel-3.13.1-166.el7.noarch
# matchpathcon /var/log/svnserve
/var/log/svnserve	system_u:object_r:var_log_t:s0
# sesearch -s svnserve_t -t var_log_t -T

#

Comment 3 Milos Malik 2017-08-14 16:34:45 UTC

Following SELinux denial appears in enforcing mode when the /var/log/svnserve directory exists:
----
type=PROCTITLE msg=audit(08/14/2017 18:24:57.205:251) : proctitle=/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid -r /var/svn --log-file /var/log/svnserve/svnserve.log 
type=PATH msg=audit(08/14/2017 18:24:57.205:251) : item=0 name=/var/log/svnserve/ inode=625659 dev=fd:02 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:var_log_t:s0 nametype=PARENT 
type=CWD msg=audit(08/14/2017 18:24:57.205:251) : cwd=/ 
type=SYSCALL msg=audit(08/14/2017 18:24:57.205:251) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x55aa1fb37698 a1=O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC a2=0666 a3=0x7ffd56f870d0 items=1 ppid=1 pid=12287 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=svnserve exe=/usr/bin/svnserve subj=system_u:system_r:svnserve_t:s0 key=(null) 
type=AVC msg=audit(08/14/2017 18:24:57.205:251) : avc:  denied  { write } for  pid=12287 comm=svnserve name=svnserve dev="vda2" ino=625659 scontext=system_u:system_r:svnserve_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=dir permissive=0 
----

Following SELinux denials appear in permissive mode:
----
type=PROCTITLE msg=audit(08/14/2017 18:31:52.759:301) : proctitle=/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid -r /var/svn --log-file /var/log/svnserve/svnserve.log 
type=PATH msg=audit(08/14/2017 18:31:52.759:301) : item=1 name=/var/log/svnserve/svnserve.log inode=630343 dev=fd:02 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=CREATE 
type=PATH msg=audit(08/14/2017 18:31:52.759:301) : item=0 name=/var/log/svnserve/ inode=625659 dev=fd:02 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:var_log_t:s0 nametype=PARENT 
type=CWD msg=audit(08/14/2017 18:31:52.759:301) : cwd=/ 
type=SYSCALL msg=audit(08/14/2017 18:31:52.759:301) : arch=x86_64 syscall=open success=yes exit=3 a0=0x55c395898698 a1=O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC a2=0666 a3=0x7ffe3965e890 items=2 ppid=1 pid=18182 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=svnserve exe=/usr/bin/svnserve subj=system_u:system_r:svnserve_t:s0 key=(null) 
type=AVC msg=audit(08/14/2017 18:31:52.759:301) : avc:  denied  { open } for  pid=18182 comm=svnserve path=/var/log/svnserve/svnserve.log dev="vda2" ino=630343 scontext=system_u:system_r:svnserve_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1 
type=AVC msg=audit(08/14/2017 18:31:52.759:301) : avc:  denied  { create } for  pid=18182 comm=svnserve name=svnserve.log scontext=system_u:system_r:svnserve_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1 
type=AVC msg=audit(08/14/2017 18:31:52.759:301) : avc:  denied  { add_name } for  pid=18182 comm=svnserve name=svnserve.log scontext=system_u:system_r:svnserve_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=dir permissive=1 
type=AVC msg=audit(08/14/2017 18:31:52.759:301) : avc:  denied  { write } for  pid=18182 comm=svnserve name=svnserve dev="vda2" ino=625659 scontext=system_u:system_r:svnserve_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=dir permissive=1 
----

Comment 8 errata-xmlrpc 2018-04-10 12:38: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://access.redhat.com/errata/RHBA-2018:0763