Bug 811361 - svnserve runs as initrc_t
svnserve runs as initrc_t
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
Depends On:
Blocks: 832330 870601
  Show dependency treegraph
Reported: 2012-04-10 15:43 EDT by Milos Malik
Modified: 2013-02-21 03:35 EST (History)
2 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-160.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 870601 (view as bug list)
Last Closed: 2013-02-21 03:35:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
svnserve test policy (93.86 KB, application/octet-stream)
2012-05-28 06:40 EDT, Miroslav Grepl
no flags Details

  None (edit)
Description Milos Malik 2012-04-10 15:43:42 EDT
Description of problem:

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

How reproducible:

Steps to Reproduce:
# service svnserve status
svnserve is stopped
# run_init service svnserve start
Authenticating root.
Starting svnserve:                                         [  OK  ]
# service svnserve status
svnserve (pid  15431) is running...
# ps -efZ | grep initrc_t
system_u:system_r:initrc_t:s0   root     15431     1  0 21:42 ?        00:00:00 /usr/bin/svnserve --daemon --pid-file=/var/run/svnserve.pid
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 15442 12100  0 21:42 pts/1 00:00:00 grep initrc_t
Actual results:
* svnserve runs as initrc_t

Expected results:
* svnserve runs in its own SELinux domain
Comment 1 Milos Malik 2012-04-10 16:50:10 EDT
The daemon is not confined by SELinux. Please help SELinux folks to create a suitable policy module. You know that we should minimize the number of programs running as initrc_t, don't you?
Comment 2 Joe Orton 2012-04-16 07:35:19 EDT
I hadn't realised this daemon had no policy coverage already - it's been in RHEL since RHEL5 at least.

It is an awkward daemon since it requires an SVN repository to access, but there is no "natural" place for such... other than /srv.

Here are constraints I can think of:

- svnserve will bind/listen/accept connections on TCP port 3690
- svnserve will need full fs read/write/list (etc) access to any SVN repos on the system, maybe a special label needed?
- the daemon will write a pidfile at /var/run/svnserve.pid
- svnserve can be invoked on command-line (e.g. via ssh) by non-privileged users, in a similar way to some IMAP servers, so that mode needs to continue working
- the svnserve daemon can be configured to use SASL; is there a standard way to handle that permissions required there?

Is that sufficient to craft a policy?
Comment 3 Joe Orton 2012-04-27 06:08:34 EDT
So how do we progress this?  Can you add policy to selinux-policy for the daemon?  Is the information in comment 2 sufficient?
Comment 4 Daniel Walsh 2012-04-27 10:52:14 EDT
Joe we will be adding policies for this in the next couple of weeks.
Comment 8 Miroslav Grepl 2012-05-28 06:40:52 EDT
Created attachment 587212 [details]
svnserve test policy

The svnserve test policy. Could you test it using

# semodule -i svnserve.pp
# restorecon -R -v /usr/bin/svnserve /var/run/svnserve*

Then just test it and execute

# ausearch -m avc -ts recent

Thank you. I added this policy to Fedora.
Comment 9 RHEL Product and Program Management 2012-07-10 04:19:48 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 10 RHEL Product and Program Management 2012-07-10 21:55:49 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 14 errata-xmlrpc 2013-02-21 03:35:16 EST
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.


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