RE: MLS levels and the initial SID for kernel_t

[Jonathan Kim]

Paul,

I recall that the problems you were having were resolved after you followed
the steps I sent.
Did you follow the exact procedure I sent you?  
If not, could you let me know the exact procedure you followed?

Below are answers to your questions:

>    1. A type running at levels X1 - X2 can only transition to 
>  a subset of
>       those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not
>       s0-s9.  A comment in the 'mls' file looks like this may 
>  be the case
>       (but I am still not 100% clear on how to read this file):
>  
>       # new process labels must be dominated by the relabeling 
>  subject's
>       # clearance and sensitivity level changes require privilege
>       mlsconstrain process transition
>           (( h1 dom h2 ) and
>            (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
>             (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); 
We want init_t:s0-s9:c0.c127 as a result of kernel_t:s9 executing
init_exec_t binary.

The type transition happens because domain_auto_trans(kernel_t, init_exec_t,
init_t) is stated in kernel.te.

The MLS level transition happens because range_transition kernel_t
init_exec_t s0 - s9:c0.c127 is stated in kernel.te.

Now we want to make sure the above "process transition" constraint is not
preventing this transition.

Subject domain (t1) is kernel_t, effective level (l1) is s9 and clearance
level (h1) is s9.
Object domain (t2) is init_t and effective level (l2) is s0 and clearance
level (h2) is s9.

Since h1 dominates h2, then to satisfy the above constraint, one of
the following conditions needs to be met:
1. l1 eq l2, or
2. t1 == mlsprocsetsl, or
3. t1 == privrangetrans and t2 == mlsrangetrans

1 and 2 are false, but 3 is true since
privrangetrans is assigned to kernel_t  (in kernel.te)
mlsrangetrans is assigned to init_t  (in init.te)

So the above rule should not cause any problem and is correct.
Moreover all the necessary rules for the transition is provided in the
policy. 

And the dyntransition constraints have nothing to do with this topic, so we
don't have to review them here.


> -----Original Message-----
> From: Paul Moore [mailto:[e-mail]]
> Sent: Wednesday, August 03, 2005 9:26 AM
> To: Chad Hanson
> Cc: Daniel J Walsh; fedora-selinux-list(a)redhat.com
> Subject: Re: MLS levels and the initial SID for kernel_t
>   
>   
> Chad Hanson wrote:
> > The kernel on an MLS system should be at system high. There 
> is a range
> > transition rule for init to transition to s0 (system low). 
> fsck should have
> > mls privileges to read the raw devices which are protected 
> at system high,
> > the same label as the kernel. If these privileges are 
> missing we need to add
> > them into the policy.
>
>   
> > The kernel itself shouldn't be a ranged object,
it should 
> system high,
> > especially since this should also be the label of devices 
> such as kmem,
> > because they don't arbitrate access to objects, but instead 
> give access to
> > raw data (memory). Since the data is raw, the safe 
> assumption to make is
> > that the data might be system_high so it should be labeled 
> as such. The same
> > holds true for unlabeled files.
>
>   
> > Interfaces such as filesystems arbitrate access to
data and 
> make an MLS
> > decision based on the label of subject and object.
>
>   
> > -Chad
>   
> Thanks for the explanation Chad.  With not clear reason
and only a 
> problem, I was getting so frustrated with this problem that I was 
> starting to convince myself that both ways were right.
>   
> However, running the kernel at s9 puts me right back to
where 
> I started, 
> a busted system.  Looking at domains/misc/kernel.te I see the 
> following 
> lines:
>   
>   ifdef(`mls_policy', `
>   # run init with maximum MLS range
>   range_transition kernel_t init_exec_t s0 - s9:c0.c127;
>   ')
>   
> checking further I see that 'mls_policy' is
enabled and the 
> range_transition rule is in fact present in the policy.conf file (in 
> fact it is the *only* range_transition rule present).  I have 
> verified 
> that '/sbin/init' is labeled properly and even tried changing the 
> range_transition rule from s0 - s9 to simply s0 and have not had any 
> luck (a shot in the dark).
>   
> This makes me think one of three things is happening:
>   
>    1. A type running at levels X1 - X2 can
> only transition to 
>  a subset of
>       those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not
>       s0-s9.  A comment in the 'mls' file looks like this may 
>  be the case
>       (but I am still not 100% clear on how to read this file):
>  
>       # new process labels must be dominated by the relabeling 
>  subject's
>       # clearance and sensitivity level changes require privilege
>       mlsconstrain process transition
>           (( h1 dom h2 ) and
>            (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
>             (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); 
>     
mlsconstrain process dyntransition
>          (( h1 dom h2 ) and
>           (( l1 eq l2 ) or ( t1 == mlsprocsetsl )));
>   
>   2. The range_transition rule in the kernel is broken.
>   3. The range_transition rule in kernel.te is incorrectly written.
>   
> Thoughts?
>   
> >>Paul Moore wrote:
> >>
> >>
> >>>Dan's latest MLS policy RPM (as well as some past versions) has a 
> >>>patch in it, mlspol.patch, which contains the following change for 
> >>>initial_sid_contexts:
> >>>
> >>> -sid kernel        system_u:system_r:kernel_t:s0 - s9:c0.c127
> >>> +sid kernel        system_u:system_r:kernel_t:s9:c0.c127
> >>>
> >>>From what I can tell this causes some problems, the biggest 
> >>
> >>of which 
> >>
> >>>being that init starts at s9 which can cause the system to 
> >>
> >>die on boot 
> >>
> >>>when trying to fsck the filesystems.  I'm not entirely sure 
> >>
> >>why this 
> >>
> >>>change was made as I would think we would want the kernel 
> to run at 
> >>>s0-s9 or at the very least s0.  Can someone clue me in as 
> to why we 
> >>>want to run the kernel at s9 or, Dan, can you change it 
> >>
> >>back to s0 - s9?
> >>
> >>>Thanks,
> >>>
> >>
> >>I will go with either way.  I don't recall why the change was made.
> >>
>
>   
>
>   
>   
>   
>

MLS levels and the initial SID for kernel_t

[Paul Moore]

Jonathan Kim wrote:
>  Paul,
>  
>  I recall that the problems you were having were resolved after you followed
>  the steps I sent.
>  Did you follow the exact procedure I sent you?  
>  If not, could you let me know the exact procedure you followed? 
Yes, the steps you sent me a few weeks ago did work but later versions 
of the policy RPM caused it to fail.  Fresh install or upgrades both 
resulted in failure.  The reason appears to be here in 
security/selinux/ss/mls.c line 521:

  if (rangetr->dom == scontext->type &&
      rangetr->type == tcontext->type) {
       /* Set the range from the rule */
       return mls_range_set(newcontext,
	                   &rangetr->range);
  }

For some reason the 'dom'/'type' values for the only rule in
'rangetr' 
do not match with the values of 'kernel_t' and 'init_exec_t' in 
'scontext->type' and 'tcontext->type' respectively.  Looking at the

range_transition types in the binary policy file, policy.19, the types 
in the file appear to match the types stored in 'rangetr' which appear 
to match the 'kernel_t' and 'init_exec_t' type values inside of 
checkpolicy-1.25.3/policy_parse.y as returned by the following lines of 
debug code I inserted:

  {
    type_datum_t *kt, *it;

    kt = hashtab_search(policydbp->p_types.table, "kernel_t");
    it = hashtab_search(policydbp->p_types.table, "init_exec_t");

    printf("PMD(#4): kernel_t=%u init_exec_t=%u\n",
           kt->value,
	  it->value);
  }

This is where I am currently at, trying to figure out why 
'scontext->type' and 'tcontext->type' appear to change values in the

kernel ... or why I am barking up the wrong tree :)  If anyone has any 
suggestions I am all ears ...

>  Below are answers to your questions:
>  
>  
> >  1. A type running at levels X1 - X2 can only transition to 
> >a subset of
> >     those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not
> >     s0-s9.  A comment in the 'mls' file looks like this may 
> >be the case
> >     (but I am still not 100% clear on how to read this file):
> >
> >     # new process labels must be dominated by the relabeling 
> >subject's
> >     # clearance and sensitivity level changes require privilege
> >     mlsconstrain process transition
> >         (( h1 dom h2 ) and
> >          (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
> >           (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
>  
>  
>  We want init_t:s0-s9:c0.c127 as a result of kernel_t:s9 executing
>  init_exec_t binary.
>  
>  The type transition happens because domain_auto_trans(kernel_t, init_exec_t,
>  init_t) is stated in kernel.te.
>  
>  The MLS level transition happens because range_transition kernel_t
>  init_exec_t s0 - s9:c0.c127 is stated in kernel.te.
>  
>  Now we want to make sure the above "process transition" constraint is not
>  preventing this transition.
>  
>  Subject domain (t1) is kernel_t, effective level (l1) is s9 and clearance
>  level (h1) is s9.
>  Object domain (t2) is init_t and effective level (l2) is s0 and clearance
>  level (h2) is s9.
>  
>  Since h1 dominates h2, then to satisfy the above constraint, one of
>  the following conditions needs to be met:
>  1. l1 eq l2, or
>  2. t1 == mlsprocsetsl, or
>  3. t1 == privrangetrans and t2 == mlsrangetrans
>  
>  1 and 2 are false, but 3 is true since
>  privrangetrans is assigned to kernel_t  (in kernel.te)
>  mlsrangetrans is assigned to init_t  (in init.te)
>  
>  So the above rule should not cause any problem and is correct.
>  Moreover all the necessary rules for the transition is provided in the
>  policy. 
>  
>  And the dyntransition constraints have nothing to do with this topic, so we
>  don't have to review them here.
>  
>  
>  
> >-----Original Message-----
> >From: Paul Moore [mailto:[e-mail]]
> >Sent: Wednesday, August 03, 2005 9:26 AM
> >To: Chad Hanson
> >Cc: Daniel J Walsh; fedora-selinux-list(a)redhat.com
> >Subject: Re: MLS levels and the initial SID for kernel_t
> >
> >
> >Chad Hanson wrote:
> >
> >>The kernel on an MLS system should be at system high. There 
> >
> >is a range
> >
> >>transition rule for init to transition to s0 (system low). 
> >
> >fsck should have
> >
> >>mls privileges to read the raw devices which are protected 
> >
> >at system high,
> >
> >>the same label as the kernel. If these privileges are 
> >
> >missing we need to add
> >
> >>them into the policy.
> >>
> >>The kernel itself shouldn't be a ranged object, it should 
> >
> >system high,
> >
> >>especially since this should also be the label of devices 
> >
> >such as kmem,
> >
> >>because they don't arbitrate access to objects, but instead 
> >
> >give access to
> >
> >>raw data (memory). Since the data is raw, the safe 
> >
> >assumption to make is
> >
> >>that the data might be system_high so it should be labeled 
> >
> >as such. The same
> >
> >>holds true for unlabeled files.
> >>
> >>Interfaces such as filesystems arbitrate access to data and 
> >
> >make an MLS
> >
> >>decision based on the label of subject and object.
> >>
> >>-Chad
> >
> >Thanks for the explanation Chad.  With not clear reason and only a 
> >problem, I was getting so frustrated with this problem that I was 
> >starting to convince myself that both ways were right.
> >
> >However, running the kernel at s9 puts me right back to where 
> >I started, 
> >a busted system.  Looking at domains/misc/kernel.te I see the 
> >following 
> >lines:
> >
> >  ifdef(`mls_policy', `
> >  # run init with maximum MLS range
> >  range_transition kernel_t init_exec_t s0 - s9:c0.c127;
> >  ')
> >
> >checking further I see that 'mls_policy' is enabled and the 
> >range_transition rule is in fact present in the policy.conf file (in 
> >fact it is the *only* range_transition rule present).  I have 
> >verified 
> >that '/sbin/init' is labeled properly and even tried changing the 
> >range_transition rule from s0 - s9 to simply s0 and have not had any 
> >luck (a shot in the dark).
> >
> >This makes me think one of three things is happening:
> >
> >  1. A type running at levels X1 - X2 can only transition to 
> >a subset of
> >     those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not
> >     s0-s9.  A comment in the 'mls' file looks like this may 
> >be the case
> >     (but I am still not 100% clear on how to read this file):
> >
> >     # new process labels must be dominated by the relabeling 
> >subject's
> >     # clearance and sensitivity level changes require privilege
> >     mlsconstrain process transition
> >         (( h1 dom h2 ) and
> >          (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
> >           (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
> >     mlsconstrain process dyntransition
> >         (( h1 dom h2 ) and
> >          (( l1 eq l2 ) or ( t1 == mlsprocsetsl )));
> >
> >  2. The range_transition rule in the kernel is broken.
> >  3. The range_transition rule in kernel.te is incorrectly written.
> >
> >Thoughts?
> >
> >
> >>>Paul Moore wrote:
> >>>
> >>>
> >>>
> >>>>Dan's latest MLS policy RPM (as well as some past versions) has a 
> >>>>patch in it, mlspol.patch, which contains the following change for 
> >>>>initial_sid_contexts:
> >>>>
> >>>>-sid kernel        system_u:system_r:kernel_t:s0 - s9:c0.c127
> >>>>+sid kernel        system_u:system_r:kernel_t:s9:c0.c127
> >>>>
> >>>
> >>>>From what I can tell this causes some problems, the biggest 
> >>>
> >>>of which 
> >>>
> >>>
> >>>>being that init starts at s9 which can cause the system to 
> >>>
> >>>die on boot 
> >>>
> >>>
> >>>>when trying to fsck the filesystems.  I'm not entirely sure 
> >>>
> >>>why this 
> >>>
> >>>
> >>>>change was made as I would think we would want the kernel 
> >
> >to run at 
> >
> >>>>s0-s9 or at the very least s0.  Can someone clue me in as 
> >
> >to why we 
> >
> >>>>want to run the kernel at s9 or, Dan, can you change it 
> >>>
> >>>back to s0 - s9?
> >>>
> >>>
> >>>>Thanks,
> >>>>
> >>>
> >>>I will go with either way.  I don't recall why the change was made.
> >>>
> >>
> >>
> >
>  
>   

-- 
. paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. paul.moore(a)hp.com                                      hewlett packard
. [phone]                                          linux security

MLS levels and the initial SID for kernel_t

[Paul Moore]

Paul Moore wrote:
>  Jonathan Kim wrote:
>  
> > Paul,
> >
> > I recall that the problems you were having were resolved after you 
> > followed
> > the steps I sent.
> > Did you follow the exact procedure I sent you?  If not, could you let 
> > me know the exact procedure you followed?
>  
>  
>  Yes, the steps you sent me a few weeks ago did work but later versions 
>  of the policy RPM caused it to fail.  Fresh install or upgrades both 
>  resulted in failure.  The reason appears to be here in 
>  security/selinux/ss/mls.c line 521:
>  
>   if (rangetr->dom == scontext->type &&
>       rangetr->type == tcontext->type) {
>        /* Set the range from the rule */
>        return mls_range_set(newcontext,
>                         &rangetr->range);
>   }
>  
>  For some reason the 'dom'/'type' values for the only rule in
> 'rangetr' 
>  do not match with the values of 'kernel_t' and 'init_exec_t' in 
>  'scontext->type' and 'tcontext->type' respectively.  Looking at the
>
>  range_transition types in the binary policy file, policy.19, the types 
>  in the file appear to match the types stored in 'rangetr' which appear 
>  to match the 'kernel_t' and 'init_exec_t' type values inside of 
>  checkpolicy-1.25.3/policy_parse.y as returned by the following lines of 
>  debug code I inserted:
>  
>   {
>     type_datum_t *kt, *it;
>  
>     kt = hashtab_search(policydbp->p_types.table, "kernel_t");
>     it = hashtab_search(policydbp->p_types.table, "init_exec_t");
>  
>     printf("PMD(#4): kernel_t=%u init_exec_t=%u\n",
>            kt->value,
>        it->value);
>   }
>  
>  This is where I am currently at, trying to figure out why 
>  'scontext->type' and 'tcontext->type' appear to change values in
> the 
>  kernel ... or why I am barking up the wrong tree :)  If anyone has any 
>  suggestions I am all ears ...
>   
I found the problem, it was in libsepol.  I just posted a patch over on 
the SELinux Developers list.

-- 
. paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. paul.moore(a)hp.com                                      hewlett packard
. [phone]                                          linux security