1 |
On Sat, Aug 20, 2011 at 08:08:41PM -0500, Chris Richards wrote: |
2 |
> > Yet we will eventually need to support this, because otherwise we need to |
3 |
> > "open" the privileges on initrc_t towards all potential services. Not only |
4 |
> > does that require lots of work, it also brings in patches in our policy |
5 |
> > that |
6 |
> > upstream will never accept (and they're right not to accept it). |
7 |
> |
8 |
> Ok, I buy the argument. Is this a shortcoming in the old bash init, or is |
9 |
> this a shortcoming in OpenRC? |
10 |
> |
11 |
> I'm starting to see a little more free time from my job and might be able |
12 |
> to tackle some things starting in a couple of weeks. |
13 |
|
14 |
I'm not sure. A quick check reveals that there is no such thing as |
15 |
domain-specific initrc_t subdomains. It seems that the subdomains are there |
16 |
to allow roles within SELinux to handle init scripts of one daemon but not |
17 |
the other (for instance, create an ldapadm_r which has ldap_admin() and as |
18 |
such is allowed to execute it properly, but doesn't have the same rights for |
19 |
postfix). |
20 |
|
21 |
Within Gentoo, we mark everything as initrc_exec_t, so the user needs just |
22 |
"one" privilege to handle services for all domains. I'd like to "fix" that, |
23 |
but still keep the integrated run_init support in-place. That'll require |
24 |
some more investigation here (since I don't understand how the integrated |
25 |
run_init is done). |
26 |
|
27 |
However, my initial assessment that we "otherwise" need to "open" up |
28 |
initrc_t stays in place (we just don't have a choice here). That initrc_t |
29 |
is a highly privileged domain is obvious from a first look at its .te file. |
30 |
So it looks as if we just need to add the proper optional_policy statements |
31 |
here. |
32 |
|
33 |
BTW, glad to hear you're seeing some free time in the near future ;-) |
34 |
|
35 |
Wkr, |
36 |
Sven Vermeulen |