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?
joe
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.
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?
joe
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 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.
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.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Joe Nall -
Stephen Smalley