2:55 p.m.
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
3:18 p.m.
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.
--
Stephen Smalley
National Security Agency
8 p.m.
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
10:08 a.m.
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
12:21 p.m.
New subject: service and system-config-services restart daemons in incorrect type under mls policy
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.
12:30 p.m.
New subject: service and system-config-services restart daemons in incorrect type under mls policy
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
6206
days inactive
6207
days old
selinux@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Daniel J Walsh -
Joe Nall -
Stephen Smalley