MLS levels and the initial SID for kernel_t
Paul Moore
paul.moore at hp.com
Wed Aug 3 14:26:17 UTC 2005
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
More information about the selinux
mailing list