Summary: | Allow SELinux systems to run /etc/init.d scripts without re-running run_init every time | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Richards <gizmo> |
Component: | Hardened | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | VERIFIED FIXED | ||
Severity: | enhancement | CC: | coolio, selinux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Chris Richards
2011-05-02 21:22:33 UTC
Some quick pointers... The setting can be enabled within the reference policy by editing build.conf to say "DIRECT_INITRC = y" (default is "n"). This will add the proper attributes to sysadm_t (direct_run_init) and the exec domains of the daemons (direct_init_entry) and domains themselves (direct_init). However, it looks like when we enable this, the sysadm_r has no rights to work with initrc_exec_t (and such the current labels for /etc/init.d/* are useless). It looks like the policy wants the scripts to be labelled bin_t (no transition) so that sysadm_t can directly execute the domain_exec_t to transition to domain_t. The above analysis might be incorrect, but if not, then this isn't a change that can be made quickly: init scripts use the runscript binary, which also needs to be relabelled, and perhaps some domains need to be marked as an init_daemon_domain() to work properly. Also, it seems like all other distributions require the use of run_init (like Gentoo does - only we do this behind the scenes) so we might need to investigate why (which risks are we taking if we would support DIRECT_INITRC)? The correct way to do this on Gentoo is to alter the pam config. The Fedora way is broken. First line of run_init's pam.d entry should do it: auth sufficient pam_rootok.so Looks like this works when executing things with "run_init" directly (like "run_init /etc/init.d/local restart") but not when using the built-in support for run_init (like "/etc/init.d/local restart") which still seems to ask for authentication. Strace'ing shows that it does read in the /etc/pam.d/run_init file (and parses the line, and reads in pam_rootok.so). Perhaps the runscript_selinux.so library specifically asks for the password regardless of that setting? (In reply to comment #3) > Looks like this works when executing things with "run_init" directly (like > "run_init /etc/init.d/local restart") but not when using the built-in support > for run_init (like "/etc/init.d/local restart") which still seems to ask for > authentication. > > Strace'ing shows that it does read in the /etc/pam.d/run_init file (and parses > the line, and reads in pam_rootok.so). Perhaps the runscript_selinux.so library > specifically asks for the password regardless of that setting? I don't have the behavior on my system, after placing "auth sufficient pam_rootok.so" in the first line of run_init. After this fix, when I run built-in support for run_init(like "/etc/init.d/local restart") no authorization is required(when uid=0). Even in enforcing mode? I can't seem to reproduce that... Going to document this as a FAQ. Committed to CVS. |