Ok I plead ignorance to the way MLS works.

Ok I plead ignorance to the way MLS works.

[Daniel J Walsh]

Playing around with MCS, I see the following problems.

Should the initialsid of kernel be

sid kernel     system_u:system_r:kernel_t:s0:c0.c127
or
sid kernel     system_u:system_r:kernel_t:s0 - s0:c0.c127

I would like all the daemon processes in the system to run as "s0", Ie 
by default not have access to any labeled
data.  How do I do this?   Am I supposed to use something like:
range_transition initrc_t httpd_exec_t s0 - s0;

Trying to use this is giving me a compilation error.



-- 



--
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: Ok I plead ignorance to the way MLS works.

[Darrel Goeddel]

Daniel J Walsh wrote:
> Playing around with MCS, I see the following problems.
> 
> Should the initialsid of kernel be
> 
> sid kernel     system_u:system_r:kernel_t:s0:c0.c127
> or
> sid kernel     system_u:system_r:kernel_t:s0 - s0:c0.c127
> 
> I would like all the daemon processes in the system to run as "s0", Ie 
> by default not have access to any labeled
> data.  How do I do this?   Am I supposed to use something like:
> range_transition initrc_t httpd_exec_t s0 - s0;
> 
> Trying to use this is giving me a compilation error.

I think you would want to run the kernel would at s0:c0.c127.
Then, do a "range_transition kernel_t init_exec_t s0" to get the whole
of userspace started off with no categories present.  This is a change
from the range_transition that is ifdef'd currently for mls in kernel.te.
Are you going to have "ifdef mcs_policy" like the current
"ifdef mls_policy"?

I'm sure about the compilation error, I did a similar statement with a
toolchain that is are pre-modules - that worked.  I'm updating an FC4 box
now so I at least have something up-to-date.

-- 

Darrel

--
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: Ok I plead ignorance to the way MLS works.

[Stephen Smalley]

On Wed, 2005-08-24 at 11:44 -0500, Darrel Goeddel wrote:
> I think you would want to run the kernel would at s0:c0.c127.
> Then, do a "range_transition kernel_t init_exec_t s0" to get the whole
> of userspace started off with no categories present.

Why not just have the kernel start out at s0 (no categories), and just
give its domain the necessary attributes to override MLS?  Then you
don't need to transition at all.  Otherwise, you also have to deal with
any other kernel-invoked helpers, e.g. hotplug.

> I'm sure about the compilation error, I did a similar statement with a
> toolchain that is are pre-modules - that worked.  I'm updating an FC4 box
> now so I at least have something up-to-date.

I just tried adding the range_transition listed by Dan to a policy.conf
and rebuilding with checkpolicy -M (latest cvs), and it worked for me.
But note that s0 - s0 is unnecessary; it is the same as just s0.  The
high level defaults to the low level if it isn't specified.

-- 
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: Ok I plead ignorance to the way MLS works.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Wed, 2005-08-24 at 11:44 -0500, Darrel Goeddel wrote:
>  
>
>>I think you would want to run the kernel would at s0:c0.c127.
>>Then, do a "range_transition kernel_t init_exec_t s0" to get the whole
>>of userspace started off with no categories present.
>>    
>>
>
>Why not just have the kernel start out at s0 (no categories), and just
>give its domain the necessary attributes to override MLS?  Then you
>don't need to transition at all.  Otherwise, you also have to deal with
>any other kernel-invoked helpers, e.g. hotplug.
>
>  
>
Ok, I changed the kernel to s0, and now all domains run in s0.  Problem 
is I want root to login as
s0:c0.c127

I changed root default context file 
(/etc/selinux/targeted/contexts/users/root)  to

system_u:system_r:local_login_t:s0 system_r:unconfined_t:s0:c0.c127

But when I login I get

root:system_r:unconfined_t:s0

login is running as
system_u:system_r:local_login_t:s0 

Should it be running with a range?
Do I need to change login policy?
I see no errors...


>>I'm sure about the compilation error, I did a similar statement with a
>>toolchain that is are pre-modules - that worked.  I'm updating an FC4 box
>>now so I at least have something up-to-date.
>>    
>>
>
>I just tried adding the range_transition listed by Dan to a policy.conf
>and rebuilding with checkpolicy -M (latest cvs), and it worked for me.
>But note that s0 - s0 is unnecessary; it is the same as just s0.  The
>high level defaults to the low level if it isn't specified.
>
>  
>
Ok it was within a boolean block.


-- 



--
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: Ok I plead ignorance to the way MLS works.

[Stephen Smalley]

On Wed, 2005-08-24 at 13:27 -0400, Daniel J Walsh wrote:
> Ok, I changed the kernel to s0, and now all domains run in s0.  Problem 
> is I want root to login as
> s0:c0.c127
> 
> I changed root default context file 
> (/etc/selinux/targeted/contexts/users/root)  to
> 
> system_u:system_r:local_login_t:s0 system_r:unconfined_t:s0:c0.c127
> 
> But when I login I get
> 
> root:system_r:unconfined_t:s0
> 
> login is running as
> system_u:system_r:local_login_t:s0 
> 
> Should it be running with a range?
> Do I need to change login policy?
> I see no errors...

Hmmm...looks like you have to transition login to a range via a
range_transition rule on login_exec_t in order for the current MLS logic
to permit the user to login at a different level.

Also, I think you want root's default level to still be s0, but his
range to be s0-s0:c0.c127, so that his clearance will be set to that
value.  You want the current/low level to be s0 so that files he creates
default to no categories, but his high/clearance level to be his
authorized set of categories so that he is allowed by the MCS
constraints to set any of those categories on files he owns.

-- 
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: Ok I plead ignorance to the way MLS works.

[Chad Hanson]

 
The kernel should be treated as a system high process and everything it does
as system high. I think making the kernel system low is bad because the
kernel shouldn't need overrides to access data and objects it has direct
access to.

-Chad


-----Original Message-----
From: Stephen Smalley
To: Darrel Goeddel
Cc: Daniel J Walsh; SE Linux
Sent: 8/24/2005 12:56 PM
Subject: Re: Ok I plead ignorance to the way MLS works.

On Wed, 2005-08-24 at 11:44 -0500, Darrel Goeddel wrote:
> I think you would want to run the kernel would at s0:c0.c127.
> Then, do a "range_transition kernel_t init_exec_t s0" to get the whole
> of userspace started off with no categories present.

Why not just have the kernel start out at s0 (no categories), and just
give its domain the necessary attributes to override MLS?  Then you
don't need to transition at all.  Otherwise, you also have to deal with
any other kernel-invoked helpers, e.g. hotplug.

> I'm sure about the compilation error, I did a similar statement with a
> toolchain that is are pre-modules - that worked.  I'm updating an FC4
box
> now so I at least have something up-to-date.

I just tried adding the range_transition listed by Dan to a policy.conf
and rebuilding with checkpolicy -M (latest cvs), and it worked for me.
But note that s0 - s0 is unnecessary; it is the same as just s0.  The
high level defaults to the low level if it isn't specified.

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

--
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: Ok I plead ignorance to the way MLS works.

[James Morris]

On Wed, 24 Aug 2005, Daniel J Walsh wrote:

> Ok, I changed the kernel to s0, and now all domains run in s0.  Problem is I
> want root to login as
> s0:c0.c127
> 

This will cause all of the files created by root to be labeled with all 
categories.


- James
-- 
James Morris
<jmorris@namei.org>

--
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: Ok I plead ignorance to the way MLS works.

[Stephen Smalley]

On Wed, 2005-08-24 at 15:11 -0400, Chad Hanson wrote:
>  The kernel should be treated as a system high process and everything it does
> as system high. I think making the kernel system low is bad because the
> kernel shouldn't need overrides to access data and objects it has direct
> access to.

System high or ranged from system low to system high?  It still needs
MLS privileges to act at any level, right?

So you'd prefer transitioning to system low upon executing /sbin/init?
init will still need MLS privileges so that it can kill and reap all
processes.

And we still have to transition login to a range so that users can login
with their clearance set to their highest authorized level.

-- 
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: Ok I plead ignorance to the way MLS works.

[Chad Hanson]

 

>>System high or ranged from system low to system high?  It still needs
>>MLS privileges to act at any level, right?

System High would be preferred.  kernel_t does need MLS attributes to
override the MLS policy.


>>So you'd prefer transitioning to system low upon executing /sbin/init?
>>init will still need MLS privileges so that it can kill and reap all
>>processes.

I'd prefer the transition to run init at system low with a clearance of
system high.


>>And we still have to transition login to a range so that users can login
>>with their clearance set to their highest authorized level.

With init at system low to system high, login would handle setting the
labels.

-Chad

--
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: Ok I plead ignorance to the way MLS works.

[Daniel J Walsh]

Chad Hanson wrote:

> 
>
>  
>
>>>System high or ranged from system low to system high?  It still needs
>>>MLS privileges to act at any level, right?
>>>      
>>>
>
>System High would be preferred.  kernel_t does need MLS attributes to
>override the MLS policy.
>
>
>  
>
>>>So you'd prefer transitioning to system low upon executing /sbin/init?
>>>init will still need MLS privileges so that it can kill and reap all
>>>processes.
>>>      
>>>
>
>I'd prefer the transition to run init at system low with a clearance of
>system high.
>
>
>  
>
>>>And we still have to transition login to a range so that users can login
>>>with their clearance set to their highest authorized level.
>>>      
>>>
>
>With init at system low to system high, login would handle setting the
>labels.
>
>-Chad
>  
>
Except I don't want all the other apps started by init at anything 
higher the system low for MCS.

Dan

-- 



--
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: Ok I plead ignorance to the way MLS works.

[Chad Hanson]

 

This would be case. They would have an effective label of system low, which
is used for labeling and access purposes, and a clearance of system high.
The only processes not at system low would be those spawned by the kernel
itself instead of init. 

-Chad

-----Original Message-----
From: Daniel J Walsh
To: Chad Hanson
Cc: 'Stephen Smalley '; Darrel Goeddel; ''SE Linux ' '
Sent: 8/24/2005 4:28 PM
Subject: Re: Ok I plead ignorance to the way MLS works.

Chad Hanson wrote:

> 
>
>  
>
>>>System high or ranged from system low to system high?  It still needs
>>>MLS privileges to act at any level, right?
>>>      
>>>
>
>System High would be preferred.  kernel_t does need MLS attributes to
>override the MLS policy.
>
>
>  
>
>>>So you'd prefer transitioning to system low upon executing
/sbin/init?
>>>init will still need MLS privileges so that it can kill and reap all
>>>processes.
>>>      
>>>
>
>I'd prefer the transition to run init at system low with a clearance of
>system high.
>
>
>  
>
>>>And we still have to transition login to a range so that users can
login
>>>with their clearance set to their highest authorized level.
>>>      
>>>
>
>With init at system low to system high, login would handle setting the
>labels.
>
>-Chad
>  
>
Except I don't want all the other apps started by init at anything 
higher the system low for MCS.

Dan

-- 


--
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: Ok I plead ignorance to the way MLS works.

[Stephen Smalley]

On Wed, 2005-08-24 at 17:45 -0400, Chad Hanson wrote: 
> This would be case. They would have an effective label of system low, which
> is used for labeling and access purposes, and a clearance of system high.
> The only processes not at system low would be those spawned by the kernel
> itself instead of init. 

Understood for the real MLS policy, but under MCS, processes are allowed
to act based on their clearance, not their current level.  So Dan is
correct.

-- 
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: Ok I plead ignorance to the way MLS works.

[Chad Hanson]

Ok, I'll plead MCS ignorance :) I understand the clearance will be used for
read/write access. Should all system services have access to all files? If
not a runcon or range transition would need to occur before the service
starts. For a particular desktop/user session pam should reduce the
clearance to the desired value/range. How far off am I here?

-Chad  

-----Original Message-----
From: Stephen Smalley
To: Chad Hanson
Cc: 'Daniel J Walsh '; Darrel Goeddel; '''SE Linux ' ' '
Sent: 8/25/2005 8:53 AM
Subject: RE: Ok I plead ignorance to the way MLS works.

On Wed, 2005-08-24 at 17:45 -0400, Chad Hanson wrote: 
> This would be case. They would have an effective label of system low,
which
> is used for labeling and access purposes, and a clearance of system
high.
> The only processes not at system low would be those spawned by the
kernel
> itself instead of init. 

Understood for the real MLS policy, but under MCS, processes are allowed
to act based on their clearance, not their current level.  So Dan is
correct.

-- 
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: Ok I plead ignorance to the way MLS works.

[Stephen Smalley]

On Thu, 2005-08-25 at 17:04 -0400, Chad Hanson wrote:
> Ok, I'll plead MCS ignorance :) I understand the clearance will be used for
> read/write access. Should all system services have access to all files? If
> not a runcon or range transition would need to occur before the service
> starts. For a particular desktop/user session pam should reduce the
> clearance to the desired value/range. How far off am I here?

As I understand it, most system services should not have access to all
categories in MCS, although some services (cups?) may require such
access.   Hence, either starting kernel_t with a clearance that has no
categories or shedding them upon init seemed preferable, then using a
range_transition to regain them for specific services and login
processes.  

-- 
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: Ok I plead ignorance to the way MLS works.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Thu, 2005-08-25 at 17:04 -0400, Chad Hanson wrote:
>  
>
>>Ok, I'll plead MCS ignorance :) I understand the clearance will be used for
>>read/write access. Should all system services have access to all files? If
>>not a runcon or range transition would need to occur before the service
>>starts. For a particular desktop/user session pam should reduce the
>>clearance to the desired value/range. How far off am I here?
>>    
>>
>
>As I understand it, most system services should not have access to all
>categories in MCS, although some services (cups?) may require such
>access.   Hence, either starting kernel_t with a clearance that has no
>categories or shedding them upon init seemed preferable, then using a
>range_transition to regain them for specific services and login
>processes.  
>
>  
>
Yes, a few will need clearance.  Cups, Amanda, Login programs.  Then 
some will eventually need a way  where the
admin can add clearance.  IE A web server on a private network that can 
display patient records.


-- 



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