MLS levels and the initial SID for kernel_t

[Paul Moore]

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 at hp.com                                      hewlett packard
. (603) 884-5056                                          linux security