service and system-config-services restart daemons in incorrect type under mls policy

[Stephen Smalley]

On Fri, 2007-04-27 at 13:21 -0400, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-04-26 at 20:00 -0500, Joe Nall wrote:
> >   
> >> On Apr 26, 2007, at 3:18 PM, Stephen Smalley wrote:
> >>
> >>     
> >>> On Thu, 2007-04-26 at 14:55 -0500, Joe Nall wrote:
> >>>       
> >>>> I'm running an mls/permissive policy on FC6 and service and system-
> >>>> config-services start daemons in the user's selinux context rather
> >>>> than those in /etc/selinux/mls/contexts/initrc_context. Since our
> >>>> policies use init_daemon_domain to establish domain transitions, they
> >>>> are not transitioning into the correct domain on user initiated (re)
> >>>> starts.
> >>>>
> >>>> "run_init service <service> restart" - works, but leaves us in a
> >>>> situation where documentation doesn't match experience. What is the
> >>>> right approach to getting the transitions to work properly? Patch
> >>>> service and friends? Write a more generic transition?
> >>>>         
> >>> That should be governed by the DIRECT_INITRC= setting in the refpolicy
> >>> build.conf (or as overridden on the make command line in the .spec  
> >>> file
> >>> for building the policy).  DIRECT_INITRC=y (as in -targeted) turns on
> >>> direct role transitions and domain transitions from  
> >>> sysadm_r:sysadm_t to
> >>> system_r:initrc_t and/or system_r:<daemon domain>, although we  
> >>> can't yet
> >>> automatically transition the user identity field.
> >>>
> >>> If you want the DIRECT_INITRC=n situation, then yes, you need to
> >>> integrate run_init or similar functionality into the init script  
> >>> and/or
> >>> service script infrastructure, as they have done in Hardened Gentoo.
> >>>       
> >> Why does run_init prompt for a root password rather than perform a  
> >> role check?
> >>     
> >
> > The role authorization is handled transparently by policy - if you
> > weren't in an authorized role/domain, then you couldn't use run_init to
> > transition to system_r:initrc_t anyway.  Same as with newrole.  The
> > re-authentication stage is purely a (weak) countermeasure against
> > invocation by malicious code without user consent - if we had a trusted
> > path mechanism in Linux, we'd use that instead.
> >
> >   
> Most people are adding pam_rootok to /etc/pam.d/run_init so that it will 
> work for sysadm_t.

Ok, they are certainly free to choose that approach (and it nicely
allows for either option with a single run_init binary).  As long as
they understand the rationale for it.

-- 
Stephen Smalley
National Security Agency