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

[dwalsh@redhat.com (Daniel J Walsh)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/23/2011 11:35 AM, Pierre Ossman wrote:
> 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
> 
> 
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

One idea would be to label your instance that is creating users as
login_exec_t  or sshd_exec_t

Best case would be to write some policy to allow the access, based off
one of these domains.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2KOJ8ACgkQrlYvE4MpobPxnACgl1HcV59TG118WDs/fot3cSXL
rN0AoI7KO30zMwTaEdaeq4W6VJ1OX1Po
=QXdQ
-----END PGP SIGNATURE-----