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
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 23 Mar 2011 14:14:55 -0400
Daniel J Walsh <[email protected]> wrote:
>
> One idea would be to label your instance that is creating users as
> login_exec_t or sshd_exec_t
>
sshd_t seemed a bit too blatantly wrong, but login_t might be an
acceptable temporary fix. It does seem to have the privileges needed.
I do hit another error on Fedora 14:
type=AVC msg=audit(1300960436.289:102497): avc: denied { write } for pid=9695 comm="xauth" name="3" dev=dm-0 ino=2366192 scontext=unconfined_u:unconfined_r:xauth_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=dir
I don't see this AVC on el6 and I can't recall seeing it on older
Fedoras, so this is a recent restriction. The directory it tries to
write to is /var/opt/thinlinc/sessions/<user>/<display>/, hence the
var_t.
Is this a Red Hat modification or part of refpolicy? If the former,
could the restriction be relaxed? :)
> Best case would be to write some policy to allow the access, based off
> one of these domains.
Indeed. I'd like to have a proper policy for all the privileged
processes, but time is unfortunately a restricting factor. I'll make an
attempt at sorting out a basic module for this session starting
process, but login_t will have to be plan B.
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2LFlIACgkQ7b8eESbyJLg5NQCgr6RpvSiaY8MNp8hihnk4mWpD
BC4Anj3wm0kNSlo8Shjx0TUIcsL1/VNO
=8LzC
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 24 Mar 2011 11:00:48 +0100
Pierre Ossman <[email protected]> wrote:
>
> sshd_t seemed a bit too blatantly wrong, but login_t might be an
> acceptable temporary fix. It does seem to have the privileges needed.
>
Scratch that. It works on Fedora 14, but not RHEL 6. I get:
==> secure <==
Mar 24 11:04:07 localhost tl-session: pam_selinux(thinlinc:session): Open Session
Mar 24 11:04:07 localhost tl-session: pam_selinux(thinlinc:session): Username= user1 SELinux User = unconfined_u Level= s0-s0:c0.c1023
Mar 24 11:04:07 localhost tl-session: pam_selinux(thinlinc:session): Selected Security Context user_u:user_r:policykit_grant_t:s0
Mar 24 11:04:07 localhost tl-session: pam_selinux(thinlinc:session): Checking if user_u:user_r:policykit_grant_t:s0 mls range valid for user_u:user_r:policykit_grant_t:s0
Mar 24 11:04:07 localhost tl-session: pam_selinux(thinlinc:session): Security context user_u:user_r:policykit_grant_t:s0 is not allowed for user_u:user_r:policykit_grant_t:s0
==> audit/audit.log <==
type=USER_ROLE_CHANGE msg=audit(1300961047.135:33481): user pid=4696 uid=0 auid=501 ses=763 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(1300961047.136:33482): user pid=4696 uid=0 auid=501 ses=763 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'
Given that it is still saying initrc_t for tl-session, it seems that
the transition to login_t wasn't allowed. Seems t be correctly tagged
on disk:
- -rwxr-xr-x. root root system_u:object_r:login_exec_t:s0 /opt/thinlinc/libexec/tl-session
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2LGDwACgkQ7b8eESbyJLjWkQCg20ywa2nGzvgMYpz3Q8DfdA+L
v4sAoIMKg1rFx3TS6VZoWvrsyMbhGaB3
=GCaN
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/24/2011 06:00 AM, Pierre Ossman wrote:
> On Wed, 23 Mar 2011 14:14:55 -0400
> Daniel J Walsh <[email protected]> wrote:
>
>
>> One idea would be to label your instance that is creating users as
>> login_exec_t or sshd_exec_t
>
>
> sshd_t seemed a bit too blatantly wrong, but login_t might be an
> acceptable temporary fix. It does seem to have the privileges needed.
>
> I do hit another error on Fedora 14:
>
> type=AVC msg=audit(1300960436.289:102497): avc: denied { write } for pid=9695 comm="xauth" name="3" dev=dm-0 ino=2366192 scontext=unconfined_u:unconfined_r:xauth_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=dir
>
> I don't see this AVC on el6 and I can't recall seeing it on older
> Fedoras, so this is a recent restriction. The directory it tries to
> write to is /var/opt/thinlinc/sessions/<user>/<display>/, hence the
> var_t.
>
> Is this a Red Hat modification or part of refpolicy? If the former,
> could the restriction be relaxed? :)
>
>> Best case would be to write some policy to allow the access, based off
>> one of these domains.
>
> Indeed. I'd like to have a proper policy for all the privileged
> processes, but time is unfortunately a restricting factor. I'll make an
> attempt at sorting out a basic module for this session starting
> process, but login_t will have to be plan B.
>
> Rgds
You probably want to label /var/opt/thinlinc/sessions/ as
user_home_dir_t or home_root_t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2LiCoACgkQrlYvE4MpobMqwQCglLJXbUbNG7ALiDVVSjq88XKi
PZ8AnAuF/yKpaeQ27hxub57PfxA/2qgs
=kO78
-----END PGP SIGNATURE-----