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
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.
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
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?
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
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.
On Sunday 28 November 2004 04:30, Colin Walters walters@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.
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.
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
selinux@lists.fedoraproject.org
-
Colin Walters -
Karsten Wade -
Russell Coker -
Stephen Smalley