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@xxxxxx hewlett packard
. (603) 884-5056 linux security
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
