service and system-config-services restart daemons in incorrect type under mls policy
Stephen Smalley
sds at tycho.nsa.gov
Fri Apr 27 15:08:00 UTC 2007
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.
--
Stephen Smalley
National Security Agency
More information about the fedora-selinux-list
mailing list