MCS and unconfined_t

MCS and unconfined_t

[KaiGai Kohei]

Hello,

Today, I'm considering an configuration for Fedora core 5 using MCS.

Some users are associated with restricted category 'c0,c1' at most.
If user field in security context would not change, they cannot
transit to wider range of categories.

But they can login with unconfined_t domain in default.
Because unconfined_t domain has 'execcon' permission, they can
transit to discretional range of categories by re-writing the
user field in security context.

Is it possible to control the unconfined_t processes by MCS ?
It seems a bit difficult.
Please notice me, if I have misunderstanding or misconfiguration.

Thanks,

---- current configuration ----
'ymj' logins with 'officer:system_r:unconfined_t:President'.
He can transit to 'user_t:system_t:unconfined_t:God' via an evil
program calls setexeccon().
It makes all MCS configuration nonsense.

[root@ayu ~]# semanage translation -l

Level                     Translation

s0
s0-s0:c0                  Executive
s0-s0:c0,c1               President
s0-s0:c0.c255             God
s0:c0                     Secret
s0:c0,c1                  TopSecret
[root@ayu ~]# semanage user -l

                MLS/       MLS/
SELinux User    MCS Level  MCS Range        SELinux Roles

officer         s0         President        system_r
root            s0         God              sysadm_r user_r system_r
system_u        s0         God              system_r
user_u          s0         God              sysadm_r user_r system_r
[root@ayu ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               user_u                    s0
root                      root                      God
tak                       officer                   Executive
ymj                       officer                   President
[root@ayu ~]#

-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: MCS and unconfined_t

[Stephen Smalley]

On Tue, 2006-03-28 at 22:01 +0900, KaiGai Kohei wrote:
> Hello,
> 
> Today, I'm considering an configuration for Fedora core 5 using MCS.
> 
> Some users are associated with restricted category 'c0,c1' at most.
> If user field in security context would not change, they cannot
> transit to wider range of categories.
> 
> But they can login with unconfined_t domain in default.
> Because unconfined_t domain has 'execcon' permission, they can
> transit to discretional range of categories by re-writing the
> user field in security context.
> 
> Is it possible to control the unconfined_t processes by MCS ?
> It seems a bit difficult.
> Please notice me, if I have misunderstanding or misconfiguration.

Hmmm...I had thought that Russell had introduced a mlsconstraint on
process transition and dyntransition permissions in policy/mcs, see the
earlier discussion on list in Feb.  But it appears to be missing from
the current policy, which does mean that an unconfined process can
easily escape its restrictions via runcon or newrole -l.  Seems to be
missing in FC5 too.

-- 
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: MCS and unconfined_t

[Russell Coker]

On Wednesday 29 March 2006 08:27, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Is it possible to control the unconfined_t processes by MCS ?
> > It seems a bit difficult.
> > Please notice me, if I have misunderstanding or misconfiguration.
>
> Hmmm...I had thought that Russell had introduced a mlsconstraint on
> process transition and dyntransition permissions in policy/mcs, see the
> earlier discussion on list in Feb.  But it appears to be missing from
> the current policy, which does mean that an unconfined process can
> easily escape its restrictions via runcon or newrole -l.  Seems to be
> missing in FC5 too.

The problem we have is that we want su(1) to allow changing to the SE Linux 
context of the new user with the appropriate MCS categories.  To do this we 
need to have su run in it's own domain so that it is permitted to increase 
the categories while the unconfined_t domain isn't.  I plan to release this 
as an FC5 update.

For the moment KaiGai Kohei is correct and there is no way to effectively 
constrain unconfined_t.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: MCS and unconfined_t

[Stephen Smalley]

On Wed, 2006-03-29 at 11:36 +1100, Russell Coker wrote:
> The problem we have is that we want su(1) to allow changing to the SE Linux 
> context of the new user with the appropriate MCS categories.  To do this we 
> need to have su run in it's own domain so that it is permitted to increase 
> the categories while the unconfined_t domain isn't.  I plan to release this 
> as an FC5 update.
> 
> For the moment KaiGai Kohei is correct and there is no way to effectively 
> constrain unconfined_t.

Hmm...but su no longer uses pam_selinux, so it isn't supposed to change
SELinux context (aside from automatic transitions).

-- 
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: MCS and unconfined_t

[Christopher J. PeBenito]

On Tue, 2006-03-28 at 16:27 -0500, Stephen Smalley wrote:
> On Tue, 2006-03-28 at 22:01 +0900, KaiGai Kohei wrote:
> > Today, I'm considering an configuration for Fedora core 5 using MCS.
> > 
> > Some users are associated with restricted category 'c0,c1' at most.
> > If user field in security context would not change, they cannot
> > transit to wider range of categories.
> > 
> > But they can login with unconfined_t domain in default.
> > Because unconfined_t domain has 'execcon' permission, they can
> > transit to discretional range of categories by re-writing the
> > user field in security context.
> > 
> > Is it possible to control the unconfined_t processes by MCS ?
> > It seems a bit difficult.
> > Please notice me, if I have misunderstanding or misconfiguration.
> 
> Hmmm...I had thought that Russell had introduced a mlsconstraint on
> process transition and dyntransition permissions in policy/mcs, see the
> earlier discussion on list in Feb.  But it appears to be missing from
> the current policy, which does mean that an unconfined process can
> easily escape its restrictions via runcon or newrole -l.  Seems to be
> missing in FC5 too.

My issue with that patch was that it had types hardcoded into the
constraints, violating encapsulation.  In the interim other parts of the
patch were fixed and resubmitted, but this piece got lost along the way.
I've committed it, using an attribute and an interface.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: MCS and unconfined_t

[Stephen Smalley]

On Wed, 2006-03-29 at 11:29 -0500, Christopher J. PeBenito wrote:
> My issue with that patch was that it had types hardcoded into the
> constraints, violating encapsulation.  In the interim other parts of the
> patch were fixed and resubmitted, but this piece got lost along the way.
> I've committed it, using an attribute and an interface.

Ok, but it seems like something still isn't quite conceptually here in
MCS - pam_selinux was removed from su, so su isn't supposed to switch
levels, yet running su on FC5 does change to a fully ranged context,
presumably via range_transition.  Which makes no sense to me at all
given the intent of MCS.

-- 
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: MCS and unconfined_t

[Christopher J. PeBenito]

On Wed, 2006-03-29 at 11:45 -0500, Stephen Smalley wrote:
> On Wed, 2006-03-29 at 11:29 -0500, Christopher J. PeBenito wrote:
> > My issue with that patch was that it had types hardcoded into the
> > constraints, violating encapsulation.  In the interim other parts of the
> > patch were fixed and resubmitted, but this piece got lost along the way.
> > I've committed it, using an attribute and an interface.
> 
> Ok, but it seems like something still isn't quite conceptually here in
> MCS - pam_selinux was removed from su, so su isn't supposed to switch
> levels, yet running su on FC5 does change to a fully ranged context,
> presumably via range_transition.  Which makes no sense to me at all
> given the intent of MCS.

Agreed.  My guess is that it is left over from when su did have
pam_selinux.  It probably should be removed.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: MCS and unconfined_t

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Wed, 2006-03-29 at 11:45 -0500, Stephen Smalley wrote:
>> On Wed, 2006-03-29 at 11:29 -0500, Christopher J. PeBenito wrote:
>>> My issue with that patch was that it had types hardcoded into the
>>> constraints, violating encapsulation.  In the interim other parts of the
>>> patch were fixed and resubmitted, but this piece got lost along the way.
>>> I've committed it, using an attribute and an interface.
>> Ok, but it seems like something still isn't quite conceptually here in
>> MCS - pam_selinux was removed from su, so su isn't supposed to switch
>> levels, yet running su on FC5 does change to a fully ranged context,
>> presumably via range_transition.  Which makes no sense to me at all
>> given the intent of MCS.
> 
> Agreed.  My guess is that it is left over from when su did have
> pam_selinux.  It probably should be removed.

Does 'that patch' mean what Russell posted on 03/Feb, doesn't it?
I think there is another issue other than violating encapsulation.

+mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
+		( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t ) or
+		( t1 == kernel_t ));

It says an process can transit to more restricted categories only
by (h1 dom h2). I felt it's over restriction.
For example, a user login with 's0' cannot transit to any wider range
categories, even if he would be allowed to belong 's0-s0:c0.c2' at most.

I modified my desktop environment (FC5). At a moment, the following
configuration seems to me working fine.
Do you think it's a reasonable solution ?

1. remove range_transition for su/sudo
 'range_transition unconfined_t su_exec_t s0 - s0:c0.c255;'
 is not necessary for su, I also think.

2. add a constraint for changing user
 'constrain process { transition } (u1 == system_u) or (u1 == u2);'
 is necessary to restrict unbounded transition between categories.
 system_u is an exception because logind/sshd need to change user name.
 (It should be replaced by macros from the refpolicy sight.)

3. associate root with system_u
 Because transition from root to system_u is denied by constrain (2),
 starting or restarting any services by hand is impossible.
 Threfore, I associate root with same user for any daemons.

Thanks,

-------------------------------------------
[root@saba ~]# semanage login -l
Login Name        SELinux User       MLS/MCS Range
__default__       user_u             s0
root              system_u           God
tak               officer            Executive
ymj               officer            President

[root@saba ~]# semanage user -l
                MLS/       MLS/
SELinux User    MCS Level  MCS Range          SELinux Roles
officer         s0         President          system_r
root            s0         God                sysadm_r user_r system_r
system_u        s0         God                system_r
user_u          s0         God                sysadm_r user_r system_r

[root@saba ~]# semanage translation -l
Level                     Translation
s0
s0-s0:c0                  Manager
s0-s0:c0,c1               Executive
s0-s0:c0.c2               President
s0-s0:c0.c255             God
s0:c0                     Confidential
s0:c0.c1                  Secret
s0:c0.c2                  TopSecret


[tak@saba ~]$ id -Z
officer:system_r:unconfined_t:Executive
[tak@saba ~]$ runcon -u user_u /bin/bash
execvp: Permission denied
[tak@saba ~]$ runcon -l President /bin/bash
[tak@saba ~]$ id -Z
officer:system_r:unconfined_t:President
[tak@saba ~]$ runcon -l God /bin/bash
officer:system_r:unconfined_t:God is not a valid context

--
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: MCS and unconfined_t

[Russell Coker]

On Thursday 30 March 2006 14:57, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> Christopher J. PeBenito wrote:
> > On Wed, 2006-03-29 at 11:45 -0500, Stephen Smalley wrote:
> >> On Wed, 2006-03-29 at 11:29 -0500, Christopher J. PeBenito wrote:
> >>> My issue with that patch was that it had types hardcoded into the
> >>> constraints, violating encapsulation.  In the interim other parts of
> >>> the patch were fixed and resubmitted, but this piece got lost along the
> >>> way. I've committed it, using an attribute and an interface.
> >>
> >> Ok, but it seems like something still isn't quite conceptually here in
> >> MCS - pam_selinux was removed from su, so su isn't supposed to switch
> >> levels, yet running su on FC5 does change to a fully ranged context,
> >> presumably via range_transition.  Which makes no sense to me at all
> >> given the intent of MCS.
> >
> > Agreed.  My guess is that it is left over from when su did have
> > pam_selinux.  It probably should be removed.
>
> Does 'that patch' mean what Russell posted on 03/Feb, doesn't it?
> I think there is another issue other than violating encapsulation.

Yes.

> +mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
> +		( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t ) or
> +		( t1 == kernel_t ));
>
> It says an process can transit to more restricted categories only
> by (h1 dom h2). I felt it's over restriction.
> For example, a user login with 's0' cannot transit to any wider range
> categories, even if he would be allowed to belong 's0-s0:c0.c2' at most.

That is intentional.  The reason for this is that a user may want to run a 
process with a sub-set of their access.  One reason for doing so is dealing 
with untrusted code.  Another reason is to avoid having to make manual 
decisions about labeling and avoiding accidental relabeling.  If the user has 
categories c0 and c1, then they can use s0:c0-s0:c0 for accessing files with 
sensitivity s0:c0, this prevents reading files with category c1 and also 
prevents accidentally reading data from a s0:c0 file and writing it to a s0 
file (files will be created as s0:c0 by default).

> I modified my desktop environment (FC5). At a moment, the following
> configuration seems to me working fine.
> Do you think it's a reasonable solution ?
>
> 1. remove range_transition for su/sudo
>  'range_transition unconfined_t su_exec_t s0 - s0:c0.c255;'
>  is not necessary for su, I also think.

Yes, I believe that this is required as su no longer supports changing roles.

> 2. add a constraint for changing user
>  'constrain process { transition } (u1 == system_u) or (u1 == u2);'
>  is necessary to restrict unbounded transition between categories.
>  system_u is an exception because logind/sshd need to change user name.
>  (It should be replaced by macros from the refpolicy sight.)

Currently when the administrator restarts sshd the sshd process gets the 
identity of the administrator (usually "root").  I don't think that we want 
to go down the path of changing the mlsconstrain rules when adding new user 
identities.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: MCS and unconfined_t

[Stephen Smalley]

On Thu, 2006-03-30 at 12:57 +0900, KaiGai Kohei wrote:
> +mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
> +		( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t ) or
> +		( t1 == kernel_t ));
> 
> It says an process can transit to more restricted categories only
> by (h1 dom h2). I felt it's over restriction.
> For example, a user login with 's0' cannot transit to any wider range
> categories, even if he would be allowed to belong 's0-s0:c0.c2' at most.
> 
> I modified my desktop environment (FC5). At a moment, the following
> configuration seems to me working fine.
> Do you think it's a reasonable solution ?

The reason that we need the stronger restriction above is that there is
not a one-to-one mapping from Linux users to SELinux users, and we are
now relying on the seusers mapping and initial setup by login to bound
what is reachable by a given Linux user.  For example, two different
Linux users might be mapped to user_u but with different category sets
by seusers, and the underlying policy will authorize user_u for the
combination of those category sets so that both security contexts are
valid.  Thus, if we allow the process to later escalate its categories
to anything permitted in the security context by policy, it can escape
the per-Linux-user restrictions.

-- 
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: MCS and unconfined_t

[KaiGai Kohei]

>>It says an process can transit to more restricted categories only
>>by (h1 dom h2). I felt it's over restriction.
>>For example, a user login with 's0' cannot transit to any wider range
>>categories, even if he would be allowed to belong 's0-s0:c0.c2' at most.
>>
>>I modified my desktop environment (FC5). At a moment, the following
>>configuration seems to me working fine.
>>Do you think it's a reasonable solution ?
> 
> 
> The reason that we need the stronger restriction above is that there is
> not a one-to-one mapping from Linux users to SELinux users, and we are
> now relying on the seusers mapping and initial setup by login to bound
> what is reachable by a given Linux user.

Hmm... a one-to-one mapping between Linux users and SELinux users might
indeed cause managements nightmare.
Please forget my previous proposition.

Thanks Russell for providing modified RPM package. Now I'm using it with
a bit modification removing range_transition of su_exec_t.

By th way, do you think an additional mlsconstrain is necessary for
security : {load_policy setenforce setbool} ?
It also makes MCS invalid, I think.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: MCS and unconfined_t

[Russell Coker]

On Thursday 30 March 2006 03:29, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> > Hmmm...I had thought that Russell had introduced a mlsconstraint on
> > process transition and dyntransition permissions in policy/mcs, see the
> > earlier discussion on list in Feb.  But it appears to be missing from
> > the current policy, which does mean that an unconfined process can
> > easily escape its restrictions via runcon or newrole -l.  Seems to be
> > missing in FC5 too.
>
> My issue with that patch was that it had types hardcoded into the
> constraints, violating encapsulation.  In the interim other parts of the
> patch were fixed and resubmitted, but this piece got lost along the way.
> I've committed it, using an attribute and an interface.

http://people.redhat.com/rcoker/pol/

At the above URL I've put some packages for rawhide that fix this issue and a 
few other things.

Among the changes is the change to file contexts to separate /usr(/.*)? 
into /usr -d and /usr/.* etc.  This causes a relabel of most of the system on 
package install (so I'm not planning to put it in FC5), but gives a small 
performance increase on setfiles/restorecon etc once it's in place.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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.