On 03/13/2015 10:31 PM, Dominick Grift wrote:
> On Fri, Mar 13, 2015 at 09:17:36PM +0000, Higgs, Stephen wrote:
>>>>>> Hello all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> If there is a more appropriate forum for this question please let me know:
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have a system that uses confined users by default and some files
>>>>>> are managed by a puppet server.  When I run (via run_init) the
>>>>>> puppet startup script, I get the following avc log:
>>>>>>
>>>>>>
>>>>>>
>>>>>> avc: denied { relabelto } for pid=30707 comm="puppet" name="crl.pem"
>>>>>> dev=dm-1 ino=527257 scontext=system_u:system_r:puppet_t:s0
>>>>>> tcontext=system_u:object_r:puppet_var_lib_t:s0:c0.c1023 tclass=file
>>>>>>
>>>>>> I added "typeattribute puppet_t can_change_object_identity" and
>>>>>> appropriate "allow" statements to the puppet_t type after reading
>>>>>> the constraints in the targeted policy. However, it was the category
>>>>>> "s0:c0.c1023" that was also preventing puppet from relabeling the
>>>>>> crl.pem file.
>>>>>>
>>>>>> I was able to fix this by manually relabeling the file to "s0"
>>>>>> instead of "s0:c0.c1023". My question is, how *should* I handle this
>>>>>> so puppet can handle the relabel of the category?
>>>>> It requires an appropriate attribute for the mcs or mls constraint
>>>>> that is blocking access.  Which attribute depends on your policy; MCS
>>>>> in particular has changed a lot over time in Fedora and RHEL.  What distro &
>>> version?
>>>> I'm using CentOS / RedHat 6.6, targeted reference policy 24.
>>> Hmmm...looking at selinux-policy-3.7.19-260.el6.src.rpm,
>>> serefpolicy-3.719/policy/mcs has this:
>>>
>>> # New filesystem object labels must be dominated by the relabeling subject #
>>> clearance, also the objects are single-level.
>>> mlsconstrain file { create relabelto }
>>>          (( h1 dom h2 ) and ( l2 eq h2 ));
>>>
>>> So no attributes are exempted from that constraint; your only option is to run
>>> puppet ranged (i.e. as system_u:system_r:puppet_t:s0-s0:c0.c1023)
>>> so that its high level dominates any potential file level.
Yes, there is no attribute on RHEL6.
>>>
>>> You should be able to do that with a range_transition rule, e.g.
>>> range_transition initrc_t puppet_exec_t:process s0 - s0:c0.c0123; (assuming
>>> that the puppet entrypoint is labeled with puppet_exec_t).
>> Thanks Stephen, this makes sense to me, but I can't get that statement to compile in my policy module:
>>
>>     Compiling targeted puppet module
>>     /usr/bin/checkmodule:  loading policy configuration from tmp/puppet.tmp
>>     puppet.te":14:ERROR 'unknown level s0-s0 used in range_transition definition' at token ';' on line 1041:
>>     range_transition initrc_t puppet_exec_t:process s0-s0:c0.c1023;
>>     #init_ranged_daemon_domain(puppet_t,puppet_exec_t,s0-s0:c0.c1023);
>>     /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>>     make: *** [tmp/puppet.mod] Error 1
>>
>> I did try checkmodule as well, and I tried using the init_ranged_daemon_domain macro.  Here is the policy module that I am trying to compile:
>>
>>     module puppet 1.2;
>>     require {
>>             type puppet_t;
>>             type puppet_exec_t;
>>             type initrc_t;
>>             attribute can_change_object_identity;
>>             class process { transition };
>>     }
>>     typeattribute puppet_t can_change_object_identity;
>>     #init_ranged_daemon_domain(puppet_t,puppet_exec_t,s0-s0:c0.c1023);
>>     range_transition initrc_t puppet_exec_t:process s0-s0:c0.c1023;
> Not sure but try spaces here (s0 - s0): range_transition initrc_t puppet_exec_t:process s0 - s0:c0.c1023;
>
>> I feel like I'm close, but perhaps I'm missing how to import  the level definitions?
Try this one

policy_module(mypol,1.0)

require{
  type puppet_t;
  type puppet_exec_t;
}

ifdef(`enable_mcs',`
     init_ranged_daemon_domain(puppet_t, puppet_exec_t, s0 - s0:c0.c1023)
')

>>
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.