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 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
