Suggestion on fixing a old libselinux problem.

Suggestion on fixing a old libselinux problem.

[Daniel J Walsh]

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

One of the oldest bugs/wacki things about SELinux is what happens when
a login program can not calculate a login context.

Right now we have an open bug on confined users.  Basically if you
setup a confined user guest_u and attempt to login to that user via
xdm_t, you get a context of guest_u:guest_r:oddjob_mkhomedir_t:s0

selinuxdefcon pwalsh system_u:system_r:xdm_t:s0
guest_u:guest_r:oddjob_mkhomedir_t:s0

Yech.

This could be considered a security hole, but it is definitely broken.
 I have been looking at the libselinux code but this is actually
expected behavior, and I am not eager to fix it, since it might break
peoples expectations.

Eric suggested that we might want to move the problem out of
libselinux and make this a login program problem.  Make the login
programs pam_selinux a userspace manager.

After libselinux returns a context to pam_selinux it would check for
the following allow rule.

allow logindomain userdomain:login entrypoint;

Then pam_namespace would check if xdm_t is allowed a login entry point
into oddjob_mkhomedir_t, if no, blow up the login.

Comments?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk9Ojt8ACgkQrlYvE4MpobO3qQCXUS4MjJWZf1BFDWN6U7SssAL6
3gCgtKYcOb9+9A/A+GW1cwiKaR58CZY=
=Cm5O
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Suggestion on fixing a old libselinux problem.

[Stephen Smalley]

On Wed, 2012-02-29 at 15:47 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> One of the oldest bugs/wacki things about SELinux is what happens when
> a login program can not calculate a login context.
> 
> Right now we have an open bug on confined users.  Basically if you
> setup a confined user guest_u and attempt to login to that user via
> xdm_t, you get a context of guest_u:guest_r:oddjob_mkhomedir_t:s0
> 
> selinuxdefcon pwalsh system_u:system_r:xdm_t:s0
> guest_u:guest_r:oddjob_mkhomedir_t:s0
> 
> Yech.
> 
> This could be considered a security hole, but it is definitely broken.
>  I have been looking at the libselinux code but this is actually
> expected behavior, and I am not eager to fix it, since it might break
> peoples expectations.
> 
> Eric suggested that we might want to move the problem out of
> libselinux and make this a login program problem.  Make the login
> programs pam_selinux a userspace manager.
> 
> After libselinux returns a context to pam_selinux it would check for
> the following allow rule.
> 
> allow logindomain userdomain:login entrypoint;
> 
> Then pam_namespace would check if xdm_t is allowed a login entry point
> into oddjob_mkhomedir_t, if no, blow up the login.
> 
> Comments?

Last time we discussed this, I thought we agreed to migrate away from
the current usage of security_compute_user (/selinux/user) altogether
within libselinux, and replace it with a simpler userspace configuration
and logic for determining user roles and levels.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Suggestion on fixing a old libselinux problem.

[Stephen Smalley]

On Wed, 2012-02-29 at 16:22 -0500, Stephen Smalley wrote:
> On Wed, 2012-02-29 at 15:47 -0500, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > One of the oldest bugs/wacki things about SELinux is what happens when
> > a login program can not calculate a login context.
> > 
> > Right now we have an open bug on confined users.  Basically if you
> > setup a confined user guest_u and attempt to login to that user via
> > xdm_t, you get a context of guest_u:guest_r:oddjob_mkhomedir_t:s0
> > 
> > selinuxdefcon pwalsh system_u:system_r:xdm_t:s0
> > guest_u:guest_r:oddjob_mkhomedir_t:s0
> > 
> > Yech.
> > 
> > This could be considered a security hole, but it is definitely broken.
> >  I have been looking at the libselinux code but this is actually
> > expected behavior, and I am not eager to fix it, since it might break
> > peoples expectations.
> > 
> > Eric suggested that we might want to move the problem out of
> > libselinux and make this a login program problem.  Make the login
> > programs pam_selinux a userspace manager.
> > 
> > After libselinux returns a context to pam_selinux it would check for
> > the following allow rule.
> > 
> > allow logindomain userdomain:login entrypoint;
> > 
> > Then pam_namespace would check if xdm_t is allowed a login entry point
> > into oddjob_mkhomedir_t, if no, blow up the login.
> > 
> > Comments?
> 
> Last time we discussed this, I thought we agreed to migrate away from
> the current usage of security_compute_user (/selinux/user) altogether
> within libselinux, and replace it with a simpler userspace configuration
> and logic for determining user roles and levels.

I don't think we want to introduce greater complexity and more possible
failures causes into the mix for determining user contexts.  Simplest
option would be to change get_ordered_context_list() to return the empty
list / fail in that case rather than return the full reachable list from
security_compute_user.  But I'd like to get rid of / replace
security_compute_user with a solution that is mostly userspace, at most
getting the user's authorized roles and default level information from
selinuxfs but not asking the kernel to compute reachability.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Suggestion on fixing a old libselinux problem.

[Daniel J Walsh]

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

On 02/29/2012 04:34 PM, Stephen Smalley wrote:
> On Wed, 2012-02-29 at 16:22 -0500, Stephen Smalley wrote:
>> On Wed, 2012-02-29 at 15:47 -0500, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> One of the oldest bugs/wacki things about SELinux is what
>>> happens when a login program can not calculate a login
>>> context.
>>> 
>>> Right now we have an open bug on confined users.  Basically if
>>> you setup a confined user guest_u and attempt to login to that
>>> user via xdm_t, you get a context of
>>> guest_u:guest_r:oddjob_mkhomedir_t:s0
>>> 
>>> selinuxdefcon pwalsh system_u:system_r:xdm_t:s0 
>>> guest_u:guest_r:oddjob_mkhomedir_t:s0
>>> 
>>> Yech.
>>> 
>>> This could be considered a security hole, but it is definitely
>>> broken. I have been looking at the libselinux code but this is
>>> actually expected behavior, and I am not eager to fix it, since
>>> it might break peoples expectations.
>>> 
>>> Eric suggested that we might want to move the problem out of 
>>> libselinux and make this a login program problem.  Make the
>>> login programs pam_selinux a userspace manager.
>>> 
>>> After libselinux returns a context to pam_selinux it would
>>> check for the following allow rule.
>>> 
>>> allow logindomain userdomain:login entrypoint;
>>> 
>>> Then pam_namespace would check if xdm_t is allowed a login
>>> entry point into oddjob_mkhomedir_t, if no, blow up the login.
>>> 
>>> Comments?
>> 
>> Last time we discussed this, I thought we agreed to migrate away
>> from the current usage of security_compute_user (/selinux/user)
>> altogether within libselinux, and replace it with a simpler
>> userspace configuration and logic for determining user roles and
>> levels.
> 
> I don't think we want to introduce greater complexity and more
> possible failures causes into the mix for determining user
> contexts.  Simplest option would be to change
> get_ordered_context_list() to return the empty list / fail in that
> case rather than return the full reachable list from 
> security_compute_user.  But I'd like to get rid of / replace 
> security_compute_user with a solution that is mostly userspace, at
> most getting the user's authorized roles and default level
> information from selinuxfs but not asking the kernel to compute
> reachability.
> 


Meaning we should read the contents of
/etc/selinux/TYPE/contexts/users/SELINUXUSER and get the types from
there that match the type of the login program.
If that file does not exist, then fall back to
/etc/selinux/TYPE/contexts/default_context and get the type from there.

Then just check with the kernel if LOGINTYPE_T can transition to
USERTYPE_T and choose that context. Else go to the next context.  If
no context is available to transition return failure.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9PiugACgkQrlYvE4MpobP2CQCePPk7/VDAYemrbiajTY1O5FRa
XPIAoJS1JhIQAKF+cfDI/TiUt60m5+Nc
=Oejr
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Suggestion on fixing a old libselinux problem.

[Stephen Smalley]

On Thu, 2012-03-01 at 09:42 -0500, Daniel J Walsh wrote:
> On 02/29/2012 04:34 PM, Stephen Smalley wrote:
> > I don't think we want to introduce greater complexity and more
> > possible failures causes into the mix for determining user
> > contexts.  Simplest option would be to change
> > get_ordered_context_list() to return the empty list / fail in that
> > case rather than return the full reachable list from 
> > security_compute_user.  But I'd like to get rid of / replace 
> > security_compute_user with a solution that is mostly userspace, at
> > most getting the user's authorized roles and default level
> > information from selinuxfs but not asking the kernel to compute
> > reachability.
> > 
> 
> 
> Meaning we should read the contents of
> /etc/selinux/TYPE/contexts/users/SELINUXUSER and get the types from
> there that match the type of the login program.
> If that file does not exist, then fall back to
> /etc/selinux/TYPE/contexts/default_context and get the type from there.
> 
> Then just check with the kernel if LOGINTYPE_T can transition to
> USERTYPE_T and choose that context. Else go to the next context.  If
> no context is available to transition return failure.

You can use security_check_context() to see if the context is valid
(e.g. valid user:role pair) before performing a transition check.
You'll have to decide how you want it to operate in permissive mode; the
current security_compute_user() logic ignores permissive mode (via
AVC_STRICT) and thus will return the same contexts you would get in
enforcing mode.  Otherwise permissive mode may lead to users logging in
as sysadm_r rather than user_r if authorized for both.

There is also the MLS aspect, which is more complex. See
mls_setup_user_range() in the kernel.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Suggestion on fixing a old libselinux problem.

[Stephen Smalley]

On Fri, 2012-03-02 at 12:46 -0500, Stephen Smalley wrote:
> On Thu, 2012-03-01 at 09:42 -0500, Daniel J Walsh wrote:
> > On 02/29/2012 04:34 PM, Stephen Smalley wrote:
> > > I don't think we want to introduce greater complexity and more
> > > possible failures causes into the mix for determining user
> > > contexts.  Simplest option would be to change
> > > get_ordered_context_list() to return the empty list / fail in that
> > > case rather than return the full reachable list from 
> > > security_compute_user.  But I'd like to get rid of / replace 
> > > security_compute_user with a solution that is mostly userspace, at
> > > most getting the user's authorized roles and default level
> > > information from selinuxfs but not asking the kernel to compute
> > > reachability.
> > > 
> > 
> > 
> > Meaning we should read the contents of
> > /etc/selinux/TYPE/contexts/users/SELINUXUSER and get the types from
> > there that match the type of the login program.
> > If that file does not exist, then fall back to
> > /etc/selinux/TYPE/contexts/default_context and get the type from there.
> > 
> > Then just check with the kernel if LOGINTYPE_T can transition to
> > USERTYPE_T and choose that context. Else go to the next context.  If
> > no context is available to transition return failure.
> 
> You can use security_check_context() to see if the context is valid
> (e.g. valid user:role pair) before performing a transition check.
> You'll have to decide how you want it to operate in permissive mode; the
> current security_compute_user() logic ignores permissive mode (via
> AVC_STRICT) and thus will return the same contexts you would get in
> enforcing mode.  Otherwise permissive mode may lead to users logging in
> as sysadm_r rather than user_r if authorized for both.
> 
> There is also the MLS aspect, which is more complex. See
> mls_setup_user_range() in the kernel.

That might not be relevant anymore though, as I think we are taking the
level/range from seusers and using that to bound the computation.  Thus
in the common case, we end up with the seusers level/range.  So you may
not need to replicate mls_setup_user_range() in userspace.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Suggestion on fixing a old libselinux problem.

[Sven Vermeulen]

On Wed, Feb 29, 2012 at 04:34:18PM -0500, Stephen Smalley wrote:
> > On Wed, 2012-02-29 at 15:47 -0500, Daniel J Walsh wrote:
> > > Right now we have an open bug on confined users.  Basically if you
> > > setup a confined user guest_u and attempt to login to that user via
> > > xdm_t, you get a context of guest_u:guest_r:oddjob_mkhomedir_t:s0
> > > 
> > > selinuxdefcon pwalsh system_u:system_r:xdm_t:s0
> > > guest_u:guest_r:oddjob_mkhomedir_t:s0

We had a similar issue with vixie-cron. It's attempt to get an initial
context gave strange results and we had a rough time figuring out what was
the case.

Now, we recommend users to run getseuser to find out what the returned
context is on the user' system and check if it is cronjob_t [1].

[1] http://www.gentoo.org/proj/en/hardened/selinux-faq.xml#cronfails

> > Last time we discussed this, I thought we agreed to migrate away from
> > the current usage of security_compute_user (/selinux/user) altogether
> > within libselinux, and replace it with a simpler userspace configuration
> > and logic for determining user roles and levels.
> 
> I don't think we want to introduce greater complexity and more possible
> failures causes into the mix for determining user contexts.  Simplest
> option would be to change get_ordered_context_list() to return the empty
> list / fail in that case rather than return the full reachable list from
> security_compute_user. 

I agree. I find it illogical that it returns a full reachable list.

Wkr,
	Sven Vermeulen

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.