MLS policy

MLS policy

[Russell Coker]

Currently a default root login gets a default level of s2.  This means that 
daemons initially run with the range s0-s9 but run with the range s2-s9 after 
being restarted.  Should we have range-transition rules in the daemon_domain 
family of macros to deal with this?

What is the benefit of assigning root the default level of s2 anyway?

range_transition kernel_t init_exec_t s0 - s9:c0.c255;

Currently we have the above in the MLS policy.  Is it desired that we only use 
up to s9 (highest level is s15)?  Or was it an oversight that the above line 
was not changed when the extra levels were added?

-- 
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: MLS policy

[Daniel J Walsh]

Russell Coker wrote:
> Currently a default root login gets a default level of s2.  This means that 
> daemons initially run with the range s0-s9 but run with the range s2-s9 after 
> being restarted.  Should we have range-transition rules in the daemon_domain 
> family of macros to deal with this?
>
> What is the benefit of assigning root the default level of s2 anyway?
>
> range_transition kernel_t init_exec_t s0 - s9:c0.c255;
>
>   
Oversite
> Currently we have the above in the MLS policy.  Is it desired that we only use 
> up to s9 (highest level is s15)?  Or was it an oversight that the above line 
> was not changed when the extra levels were added?
>
>   


-- 



--
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: MLS policy

[Daniel J Walsh]

Russell Coker wrote:
> Currently a default root login gets a default level of s2.  This means that 
> daemons initially run with the range s0-s9 but run with the range s2-s9 after 
> being restarted.  Should we have range-transition rules in the daemon_domain 
> family of macros to deal with this?
>
>   
Shouldn't be, this is a bad build.

Policy 16 fixes it.
> What is the benefit of assigning root the default level of s2 anyway?
>
> range_transition kernel_t init_exec_t s0 - s9:c0.c255;
>
> Currently we have the above in the MLS policy.  Is it desired that we only use 
> up to s9 (highest level is s15)?  Or was it an oversight that the above line 
> was not changed when the extra levels were added?
>
>   


-- 



--
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: MLS policy

[Chad Hanson]

> 
> Currently a default root login gets a default level of s2.  This means
that 
> daemons initially run with the range s0-s9 but run with the range s2-s9
after 
> being restarted.  Should we have range-transition rules in the
daemon_domain 
> family of macros to deal with this?
> 

We do have range_transition policy to handle this. This will be included in
a MLS policy update we are working on. 

> What is the benefit of assigning root the default level of s2 anyway?
> 

Historically on MLS users login in above the lowest level. Part of this
reason is for integrity, which is not necessary for on a system with TE.

A last comment is that an MLS/RBAC/CAPP system should not allow direct root
logins, but instead just the ability to su.

-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: MLS policy

[Russell Coker]

On Saturday 15 October 2005 00:23, Chad Hanson <chanson@trustedcs.com> wrote:
> > Currently a default root login gets a default level of s2.  This means
> > that daemons initially run with the range s0-s9 but run with the range
> > s2-s9 after being restarted.  Should we have range-transition rules in the
> > daemon_domain family of macros to deal with this?
>
> We do have range_transition policy to handle this. This will be included in
> a MLS policy update we are working on.

OK.

> > What is the benefit of assigning root the default level of s2 anyway?
>
> Historically on MLS users login in above the lowest level. Part of this
> reason is for integrity, which is not necessary for on a system with TE.

Does that mean we should have a default of s2 or s0 for root?

> A last comment is that an MLS/RBAC/CAPP system should not allow direct root
> logins, but instead just the ability to su.

Why is that?

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

mls policy

[andy.suchoski]

Hello all,
I have been exploring SELinux and I am trying to figure out exactly what the mls 
policy is. I had initially thought that it was the strict policy with hierarchical labels added. I heard elsewhere that it was basically the targeted policy with hierarchical labels. But it seems to be something yet again different. 

I have installed selinux-policy-mls-2.3.2-1.fc5 as my policy. I installed the source RPM selinux-policy-2.3.2-1.fc5.src.rpm and made 2 policies from the source. One with TYPE 'targeted-mls' and the other with TYPE 'strict-mls' in the build.conf file. I felt that one of them should match the 'mls' policy installed directly from the rpm. I thought one way was to determine this was to check for the number of types defined in the policy with seinfo. I got the following results:
mls -               1497 types defined in the policy
targetedmls -  1775 types defined in the policy (from source)
strictmls -        2488 types defined in the policy (from source)

Once I saw that the number of types defined in the policy was closer with the targetedmls policy, I did some other analysis to try and account for the differences between them. I noticed that the mls (binary) policy had 47 types with the string 'secadm' in them, 49 types with the string 'sysadm' in the type and 47 with the string 'auditadm' in the type. All told the targetedmls policy had a total of 3 types containing the string 'sysadm' with no types containing 'secadm' or 'auditadm'. 

I'm puzzled. I thought if I got the source rpm, I should be able to simply create the same policy as the rpm binary distribution by specifying the TYPE in the build.conf file.

- Andy Suchoski

--
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: mls policy

[Chris PeBenito]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

On Fri, 2006-07-28 at 21:51 +0000, andy.suchoski@comcast.net wrote:
> Hello all,
> I have been exploring SELinux and I am trying to figure out exactly
> what the mls 
> policy is. I had initially thought that it was the strict policy with
> hierarchical labels added. I heard elsewhere that it was basically the
> targeted policy with hierarchical labels. But it seems to be something
> yet again different. 
[cut]
> Once I saw that the number of types defined in the policy was closer
> with the targetedmls policy, I did some other analysis to try and
> account for the differences between them. I noticed that the mls
> (binary) policy had 47 types with the string 'secadm' in them, 49
> types with the string 'sysadm' in the type and 47 with the string
> 'auditadm' in the type. All told the targetedmls policy had a total of
> 3 types containing the string 'sysadm' with no types containing
> 'secadm' or 'auditadm'. 
> 
> I'm puzzled. I thought if I got the source rpm, I should be able to
> simply create the same policy as the rpm binary distribution by
> specifying the TYPE in the build.conf file.

The Fedora policies are based on reference policy [1], which has several
configuration options.  The Fedora MLS policy is strict-mls.  It is like
the Fedora strict policy (which is strict-mcs in terms of reference
policy), except with the graphical desktop policy modules turned off,
and 16 hierarchical sensitivity levels instead of 1.

There are a few settings in build.conf that need to be set, and what you
also need to make sure is that your modules.conf (which controls which
policy modules are built) is right.

You can see the files used by Red Hat on their CVS [2].

[1] http://oss.tresys.com/projects/refpolicy
[2] http://cvs.fedora.redhat.com/viewcvs/rpms/selinux-policy/FC-5/

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]