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:paul.moore@xxxxxx]
Sent: Wednesday, August 03, 2005 9:26 AM
To: Chad Hanson
Cc: Daniel J Walsh; fedora-selinux-list@xxxxxxxxxx
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@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
