Bug 1026374 - Add a custom luci launcher allowing sane Python runtime + SELinux coexistence
Add a custom luci launcher allowing sane Python runtime + SELinux coexistence
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci (Show other bugs)
6.4
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jan Pokorný
Cluster QE
:
Depends On:
Blocks: 1023202
  Show dependency treegraph
 
Reported: 2013-11-04 09:20 EST by Jan Pokorný
Modified: 2014-10-14 00:13 EDT (History)
7 users (show)

See Also:
Fixed In Version: luci-0.26.0-60.el6
Doc Type: Bug Fix
Doc Text:
[best if re-reviewed by someone with SELinux expertise] Cause: It was found that with restructuring the way how luci is started out (in its rebase) between RHEL 6.2 and RHEL 6.3, selinux-policy package was not made aware of these changes resulting in luci process ceasing to be perceived as SELinux confined "piranha_web_t" type. Consequence: In order to coexist with SELinux in an expected way while retaining properties of new luci start procedure, new top-level script is required. Fix: Such script is added accompanied with a correct label by updated selinux-policy package (BZ#1023202). Result: Running luci process is of "piranha_web_t" type from SELinux perspective again as per the expectations.
Story Points: ---
Clone Of: 1023202
Environment:
Last Closed: 2014-10-14 00:13:03 EDT
Type: Bug
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 Jan Pokorný 2013-11-04 09:20:00 EST
A dedicated "launcher" script needed so as to fit the phased transition
as intended with paster CLI frontend of Paste.

Early heads up about its final location to the SELinux policy team
(to Miroslav assigned to the original bug) is probably needed here.

+++ This bug was initially created as a clone of Bug #1023202 +++

See the subject, reproducer:

# yum install -y
# service luci start
# ps -Zp $(service luci status | awk '{print $5;}' )

In my case, both el6.4 and el6.5 reports something like this:
> LABEL                             PID TTY          TIME CMD
> unconfined_u:system_r:initrc_t:s0 6077 ?       00:00:00 python

The full command is:

> /usr/bin/python -Es /usr/bin/paster serve --daemon --user luci \
>  --group luci --log-file=/var/log/luci/luci.log \
>  --pid-file=/var/run/luci/luci.pid --server-name=init --app-name=init \
>  /var/lib/luci/etc/luci.ini

Was told this is not expected and I can also remember that in the past,
the luci-related things were labeled piranha*_t; see e.g. [bug 737635]
showing (if I interpret scontext ~ subject context correctly) that
expected process label should be:

> unconfined_u:system_r:piranha_web_t

--- Additional comment from Miroslav Grepl on 2013-10-25 09:30:31 CEST ---

Ok, this is way how the paster is involved. Basically we did fixes in Fedora for this where we changed the way how to confine it.

http://mgrepl.wordpress.com/2012/06/20/how-would-tools-like-paster-work-with-selinux/

This is a bug for RHEL6.6.

--- Additional comment from Jan Pokorný on 2013-10-30 15:21:41 CET ---

If I read the referenced blog post correctly, we should rather provide
a custom "launcher" script just to fit the current expected phased
transition scheme involving paster (so as not to complicate the matters
in the policy)?

--- Additional comment from Miroslav Grepl on 2013-11-04 15:10:19 CET ---

Jan,
yes. We need to have a helper scripts for luci. Also I will need to back port piranha.te policy changes to RHEL6.6 to make it working.
Comment 2 Lukas Vrabec 2014-07-15 05:25:57 EDT
Jan, 
We need helper script for luci, to fix this issue as Miroslav wrote above.
Comment 3 Jan Pokorný 2014-08-04 12:42:28 EDT
Lukáši, please see [bug 1023202 comment 8].
Comment 14 errata-xmlrpc 2014-10-14 00:13:03 EDT
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.

http://rhn.redhat.com/errata/RHSA-2014-1390.html

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