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