1 |
On Sun, Aug 21, 2011 at 07:19:17PM -0400, Mike Edenfield wrote: |
2 |
>> The solution to support<domain>_initrc_exec_t must be a policy-based one |
3 |
>> afaik. I don't think it'll be too difficult to find (the places within |
4 |
>> refpolicy that are offering interfaces just for Gentoo's integrated |
5 |
>> run_init |
6 |
>> are documented), it'll just take some time to get it in proper shape. |
7 |
> |
8 |
> Is there a specific reason that the domain-specific initrc support cannot |
9 |
> be made part of run_init? Instead of reading a single default context from |
10 |
> initrc_context, you could instead label, for ex. the init script itself, |
11 |
> and have run_init use that instead? |
12 |
|
13 |
The run_init application is merely a tool to support transitions across |
14 |
roles as well. Its behavior can well be defined by the SELinux policy |
15 |
itself. |
16 |
|
17 |
What you are suggesting (label init script) is exactly what I was talking |
18 |
about: instead of having the init scripts labeled initrc_exec_t, they should |
19 |
be labeled like slapd_initrc_exec_t, postfix_initrc_exec_t, ... and Gentoo's |
20 |
integrated run_init support, which by the policy is currently only working |
21 |
on initrc_exec_t, should support those too. |
22 |
|
23 |
Since the policy defines an attribute called init_script_file_type, I hope |
24 |
to update the Gentoo-specific privileges towards this attribute rather than |
25 |
to initrc_exec_t so that the current behavior (sysadm_r can call init |
26 |
scripts directly) is retained. |
27 |
|
28 |
Then the second approach is to update - I think - the init_script_file |
29 |
interface to support the Gentoo integrated run_init as well. But that's |
30 |
something to test and find out. |
31 |
|
32 |
Wkr, |
33 |
Sven Vermeulen |