5:47 p.m.
My question about the targeted policy presumes that init re-execs itself
after loading the policy, whereby it picks up the unconfined_t domain
from the policy, as defined by a rule in
/etc/selinux/targeted/src/policy/domains/unconfined.te.
role system_r types unconfined_t;
What rule tells init to re-exec itself in the targeted policy? Or is
init doing something differently now?
Here is how far I've gotten in figuring this out.
In the strict policy there is an explicit transition rule for init. The
file programs/misc/kernel.te has this rule:
domain_auto_trans(kernel_t, init_exec_t, init_t)
In the targeted policy, kernel.te is in domains/misc/unused, so is not
called into play. Correct? The transition behavior certainly isn't
used, i.e., init transitions to unconfined_t instead of init_t.
Therefore, I'm looking for a default behavior that init falls back on
since it doesn't have specific SELinux coverage.
In macros/global_macros.te the macro domain_auto_trans(init_t,
$1_exec_t, $1_t) is defined. However, I don't find that macro used,
i.e., domain_auto_trans(init_t) or somesuch. In addition, I'm not even
sure that init would be in the domain init_t to qualify for this macro
since in targeted it's in unconfined_t.
In define(`unconfined_domain', there is this rule:
allow $1 self:process transition;
That says that init is allowed to transition to itself, but it doesn't
tell init to do the transition and seems otherwise unrelated.
Which one of these paths, if any, is leading in the right direction?
thx - Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
11:28 p.m.
On Wed, 2004-11-24 at 15:47 -0800, Karsten Wade wrote:
My question about the targeted policy presumes that init re-execs
itself
after loading the policy, whereby it picks up the unconfined_t domain
from the policy, as defined by a rule in
/etc/selinux/targeted/src/policy/domains/unconfined.te.
role system_r types unconfined_t;
This just authorizes a role for a type, it doesn't define anything
related to init.
What rule tells init to re-exec itself in the targeted policy?
Nothing in the policy tells init to re-exec itself; the code just does
it. Do you mean, how does init get the unconfined_t type? See:
In the strict policy there is an explicit transition rule for init.
The
file programs/misc/kernel.te has this rule:
domain_auto_trans(kernel_t, init_exec_t, init_t)
In the targeted policy, kernel.te is in domains/misc/unused, so is not
called into play. Correct?
Well, kernel_t is actually an alias for init_t in targeted policy,
according to apol. The kernel starts out as unconfined_t, in my reading
of initial_sid_contexts:
sid kernel user_u:system_r:unconfined_t
Thus there is no transition at all in targeted policy.
7:03 a.m.
On Wed, 2004-11-24 at 21:28, Colin Walters wrote:
On Wed, 2004-11-24 at 15:47 -0800, Karsten Wade wrote:
> My question about the targeted policy presumes that init re-execs itself
> after loading the policy, whereby it picks up the unconfined_t domain
> from the policy, as defined by a rule in
> /etc/selinux/targeted/src/policy/domains/unconfined.te.
>
> role system_r types unconfined_t;
This just authorizes a role for a type, it doesn't define anything
related to init.
I was looking for a blanket (default) rule that covered everything not
covered by policy in domains/program/*.te.
> What rule tells init to re-exec itself in the targeted policy?
Nothing in the policy tells init to re-exec itself; the code just does
it.
I got started down this pathway from this paragraph in Russell's
article:
from http://www.redhat.com/magazine/001nov04/features/selinux/
"After the policy is loaded every running process (only init and kernel
threads as the policy is loaded early in the boot) will be assigned the
security context system_u:system_r:kernel_t (NB all kernel threads
started at any time will get that context). Once init has loaded the
policy it will re-exec itself. The policy contains the rule
domain_auto_trans(kernel_t, init_exec_t, init_t). This means that when
the kernel_t domain executes a file of type init_exec_t (for example,
/sbin/init) then the domain will automatically transition to init_t (the
correct domain for /sbin/init). After that init does its usual job and
the system boots. The kernel threads continue running as kernel_t."
This doesn't describe the targeted policy, I get that. I found the
domain_auto_trans in kernel.te and found kernel.te in
domains/misc/unused in the targeted sources, so I drew the conclusion
that the behavior of init is as Russell says but the way it gets it's
context is different.
Do you mean, how does init get the unconfined_t type? See:
[snip ref. to initial_sid_contexts]
This was a part of my question
> In the strict policy there is an explicit transition rule for init. The
> file programs/misc/kernel.te has this rule:
>
> domain_auto_trans(kernel_t, init_exec_t, init_t)
>
> In the targeted policy, kernel.te is in domains/misc/unused, so is not
> called into play. Correct?
Well, kernel_t is actually an alias for init_t in targeted policy,
according to apol.
From domains/unconfined.te:
typealias unconfined_t alias { kernel_t init_t initrc_t sysadm_t rpm_t
rpm_script_t logrotate_t };
Obviously I need to commit a little more time with apol. :)
The kernel starts out as unconfined_t, in my reading
of initial_sid_contexts:
sid kernel user_u:system_r:unconfined_t
Thus there is no transition at all in targeted policy.
init is started with the unconfined_t context? Was this behavior that
changed between FC2 and FC3, or am I missing something fundamental here?
thx - Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
11:30 a.m.
On Sat, 2004-11-27 at 05:03 -0800, Karsten Wade wrote:
init is started with the unconfined_t context? Was this behavior
that
changed between FC2 and FC3, or am I missing something fundamental here?
I think the distinction is just targeted vs. strict policy; FC2 didn't
have targeted. So basically everything just starts out as unconfined,
including the kernel, and then transitions happen for a few specific
domains like httpd_t. For strict policy, I think it's pretty much as
Russell described it. Does that answer your question?
5:56 p.m.
On Sat, 2004-11-27 at 09:30, Colin Walters wrote:
On Sat, 2004-11-27 at 05:03 -0800, Karsten Wade wrote:
> init is started with the unconfined_t context? Was this behavior that
> changed between FC2 and FC3, or am I missing something fundamental here?
I think the distinction is just targeted vs. strict policy; FC2 didn't
have targeted. So basically everything just starts out as unconfined,
including the kernel, and then transitions happen for a few specific
domains like httpd_t. For strict policy, I think it's pretty much as
Russell described it. Does that answer your question?
Almost, as we work backwards. :)
When the kernel starts, it doesn't know anything about the status of
SELinux until init mounts /proc and checks for the selinuxfs type.
Right?
Once the kernel knows that SELinux is enabled, init is coded to rexec
itself under whatever default domain it has. Is that right?
And the strict policy has a rule to tell make sure init doesn't come
back as kernel_t but as init_t?
Where the targeted policy aliases unconfined_t to a whole group that
includes kernel_t and init_t.
thx - Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
10:18 p.m.
On Sat, 2004-11-27 at 15:56 -0800, Karsten Wade wrote:
When the kernel starts, it doesn't know anything about the status
of
SELinux until init mounts /proc and checks for the selinuxfs type.
Right?
Well, no; SELinux is enabled as far as the kernel is aware (unless
selinux=0 was specified on the grub boot line), but no policy is loaded
until init starts and loads it.
Once the kernel knows that SELinux is enabled, init is coded to
rexec
itself under whatever default domain it has. Is that right?
init reexecutes itself if it determines SELinux is enabled and loading
the initial policy worked, and in the strict policy that will cause a
domain transition.
And the strict policy has a rule to tell make sure init doesn't
come
back as kernel_t but as init_t?
Right, because of the domain_auto_trans you posted originally.
Where the targeted policy aliases unconfined_t to a whole group that
includes kernel_t and init_t.
Right.
1:20 a.m.
On Sunday 28 November 2004 04:30, Colin Walters <walters(a)redhat.com> wrote:
On Sat, 2004-11-27 at 05:03 -0800, Karsten Wade wrote:
> init is started with the unconfined_t context? Was this behavior that
> changed between FC2 and FC3, or am I missing something fundamental here?
I think the distinction is just targeted vs. strict policy; FC2 didn't
have targeted. So basically everything just starts out as unconfined,
including the kernel, and then transitions happen for a few specific
domains like httpd_t. For strict policy, I think it's pretty much as
Russell described it. Does that answer your question?
Incidentally I wrote the article for FC2 and then quickly updated it for FC3.
I probably should have added more material about targeted policy.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:28 a.m.
On Wed, 2004-11-24 at 18:47, Karsten Wade wrote:
Which one of these paths, if any, is leading in the right direction?
There are a set of predefined SIDs (called initial SIDs) used for
bootstrapping prior to initial policy load. When SELinux first
initializes (during kernel initialization, well before policy load), the
kernel assigns the initial task the "kernel" initial SID. Later, when
the policy is loaded, the initial SIDs are mapped to security contexts
in the policy via the initial_sid_contexts configuration, and the kernel
can begin to get SIDs dynamically from the security server. In the
strict policy, the "kernel" initial SID maps to kernel_t, and the policy
defines a transition from kernel_t to init_t upon execution of
init_exec_t, so when /sbin/init re-executes itself after loading policy,
it transitions to init_t. In the targeted policy, the "kernel" initial
SID maps to unconfined_t, and there is no transition defined in the
targeted policy upon executing init_exec_t, so /sbin/init remains in
unconfined_t even after the re-exec.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:12 p.m.
On Mon, 2004-11-29 at 06:28, Stephen Smalley wrote:
On Wed, 2004-11-24 at 18:47, Karsten Wade wrote:
> Which one of these paths, if any, is leading in the right direction?
There are a set of predefined SIDs (called initial SIDs) used for
bootstrapping prior to initial policy load. When SELinux first
initializes (during kernel initialization, well before policy load), the
kernel assigns the initial task the "kernel" initial SID. Later, when
the policy is loaded, the initial SIDs are mapped to security contexts
in the policy via the initial_sid_contexts configuration, and the kernel
can begin to get SIDs dynamically from the security server. In the
strict policy, the "kernel" initial SID maps to kernel_t, and the policy
defines a transition from kernel_t to init_t upon execution of
init_exec_t, so when /sbin/init re-executes itself after loading policy,
it transitions to init_t. In the targeted policy, the "kernel" initial
SID maps to unconfined_t, and there is no transition defined in the
targeted policy upon executing init_exec_t, so /sbin/init remains in
unconfined_t even after the re-exec.
Excellent, thank you, that makes perfect sense.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
7086
days inactive
7093
days old
selinux@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
Colin Walters -
Karsten Wade -
Russell Coker -
Stephen Smalley