On Sat, May 14, 2011 at 11:59:54AM -0500, Chris Richards wrote:
> Just posting this so that others will know about it. We determined that
> /lib64/rc/init.d needs to be relabled to initrc_state_t on the file
> system using the same relabel that we do for /dev. I believe the manual
> is being updated to add this information. In addition, a rule has to be
> added to init.fc and init.te to relabel this directory (
> /lib64/rc/init.d((/.*)? gen_context(system_u
> s0) (or something similar), as well as add the mounton privilege using
> files_mountpoint(initrc_state_t). Once that is done, there is no longer
> a need for the fstab stuff.
I just pushed selinux-base-policy-2.20101213-r15 to hardened-dev.git
overlay. It does not resolve all problems, but at least Gentoo Hardened with
SELinux now boots up properly with OpenRC (and the Gentoo SELinux handbook
has been updated with that what Chris R. said).
But there is still some work ahead.
- rc-update currently *does* *not* *work*. Not good. I know.
The problem is that rc-update (bin_t) calls /sbin/rc (initrc_exec_t) so
transitions to run_init_t which does not have the rights to write in
/etc/runlevels (etc_t). Calling rc-update with run_init doesn't help
either (transitions to initrc_t which also has no rights to write to
- rc-service works
- rc-status works if you use "run_init rc-status". Allowing rc-status to
work without run_init is possible as well (-r15 offers the
gentoo_init_manage_script_status_files interface for this which we can
apply to run_init_t, but you'll also need to add in a
term_use_unallocated_ttys(run_init_t)) but I left it out as I find it to
be an ugly situation then
- rc works if you use "run_init rc".
Now, this mixed usage of "with run_init" and "without run_init" is a pain,
especially as Gentoo tried hard not to require run_init in the first place
(well, it uses it, but in the background). This can be fixed by using
run_init in the wrappers where needed, but that requires an update on
openrc. Yet this still looks to me like the sanest approach.
Some methods can be used to work around this, like labelling the wrappers so
that they transition before /sbin/rc is called, but that looks like an ugly
situation too to me.
To fix the rc-update issue, we need to be able to run /sbin/rc without
transitioning. I'm thinking about having a copy of /sbin/rc to
/lib64/rc/sbin and have the rc-update wrapper point to that one. I can then
also do the same for rc-status (no need for run_init then, sysadm_t has the
same privileges). It seems to work fairly well on my systems, but that's
again another change just for SELinux-enabled Gentoo systems :-(
Chris R.: in https://bugs.gentoo.org/351712 the use of the wrappers was
suggested instead of symlinks (which would've caused the same problems here
I think) just for the reason that I'm writing out now. How did you resolve
the problem on your system?