Bug 1026374

Summary: Add a custom luci launcher allowing sane Python runtime + SELinux coexistence
Product: Red Hat Enterprise Linux 6 Reporter: Jan Pokorný [poki] <jpokorny>
Component: luciAssignee: Jan Pokorný [poki] <jpokorny>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.4CC: cluster-maint, dwalsh, fdinitto, jpokorny, lvrabec, rmccabe, rsteiger
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 04:13:03 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:
Bug Depends On:    
Bug Blocks: 1023202    

Description Jan Pokorný [poki] 2013-11-04 14:20:00 UTC
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 09:25:57 UTC
Jan, 
We need helper script for luci, to fix this issue as Miroslav wrote above.

Comment 3 Jan Pokorný [poki] 2014-08-04 16:42:28 UTC
Lukáši, please see [bug 1023202 comment 8].

Comment 14 errata-xmlrpc 2014-10-14 04:13:03 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.

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