[refpolicy] help getting our application ThinLinc working with the reference policy

* [refpolicy] help getting our application ThinLinc working with the reference policy
@ 2011-03-23 15:35 Pierre Ossman
  2011-03-23 18:14 ` Daniel J Walsh
  0 siblings, 1 reply; 5+ messages in thread
From: Pierre Ossman @ 2011-03-23 15:35 UTC (permalink / raw)
  To: refpolicy

Hello,

I'm afraid we've been telling our customers for quite some time to
disable SELinux as it is causing too much problems on our
installations. I do like the principles of SELinux though, so I'd very
much like to stop doing that and letting people run their systems fully
with SELinux enabled. Unfortunately I need some help getting there as I
do not understand the reference policy well enough.

First some background. Our application is a terminal server, similar to
NoMachine's NX, Citrix' XenApp or Sun's/Oracle's Sunray. The
application does some basic network communication, but largely the work
consists of starting new user session.

Our main SELinux issue has been with the transition from the privileged
main daemon to the user's session. Up until now this has generally
resulted in everything running as initrc_t, which has caused issues
like the system dbus daemon not being reachable.

We are now trying to improve this, and the first step has been to talk
to PAM so that pam_selinux gets a chance to switch contexts. This seems
to work fine on Fedora 14 where the user now gets unconfined_t instead
of initrc_t. However, on RHEL 6, pam_selinux tries to change to the
somewhat odd policykit_grant_t, fails to do so and everything just
breaks. This is what I see in the audit log:

type=LOGIN msg=audit(1300871634.740:28665): login pid=2971 uid=0 old
auid=0 new auid=501 old ses=36 new ses=37 type=USER_ROLE_CHANGE
msg=audit(1300871634.855:28666): user pid=2971 uid=0 auid=501 ses=37
subj=unconfined_u:system_r:initrc_t:s0 msg='pam:
default-context=user_u:user_r:policykit_grant_t:s0
selected-context=user_u:user_r:policykit_grant_t:s0:
exe="/opt/thinlinc/libexec/tl-session" hostname=? addr=? terminal=?
res=failed' type=USER_ROLE_CHANGE msg=audit(1300871634.855:28667): user
pid=2971 uid=0 auid=501 ses=37 subj=unconfined_u:system_r:initrc_t:s0
msg='pam: default-context=user_u:user_r:policykit_grant_t:s0
selected-context=?: exe="/opt/thinlinc/libexec/tl-session" hostname=?
addr=? terminal=? res=failed'

After some discussion on #selinux, I got the impression that initrc_t
processes are not supposed to do context switches like this, and the
results we are getting are therefore somewhat random. It was suggested
we need to define some new domain to get things reliable.

Now the big problem from my point of view is that I have a hard time
arguing for spending a lot of time writing a big module for our
application. Our customers have generally barely heard of SELinux, let
alone understand it and why they would want it, and in the end that
governs our priorities. I, personally, still think this is important
and am therefore hoping there is a smaller solution that allows our
application to continue running fairly unconfined, but lets the users
keep SELinux active and useful for everything else.

The basic architecture for session startup is this:

(a) Main, privileged daemon that is persistent and keeps track of
sessions on the machine. This is not a binary but a Python program.

(b) A privileged helper binary that is invoked for every new session.
This handles the PAM calls and is therefore where the SELinux context
switch needs to be initiated.

(c) A unprivileged helper binary that starts all the programs that make
up the user's session. This is expected to be running in the correct
user SELinux context.

My hope would be that we can create some kind of module for (b) that we
can ship and just plug in on target systems. Our customers are
generally not familiar enough with SELinux to fiddle with it themselves.

Rgds
-- 
Pierre Ossman            OpenSource-based Thin Client Technology
System Developer         Telephone: +46-13-21 46 00
Cendio AB                Web: http://www.cendio.com

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110323/715080f7/attachment.bin 

^ permalink raw reply	[flat|nested] 5+ messages in thread