Hi guys,
I wanted to all a call to seutil_relabelto_bin_policy() (through
files_relabel_all_files) within puppet but only when the
puppet_manage_all_files boolean is set.
However, it seems that this is not allowed as the
seutil_relabelto_bin_policy() interface would add an attribute to the given
type using "typeattribute", which doesn't seem to work:
/usr/bin/checkmodule: loading policy configuration from tmp/puppet.tmp
puppet.te":142:ERROR 'syntax error' at token 'typeattribute' on line 8617:
#line 142
typeattribute puppet_t can_relabelto_binary_policy;
I guess that attributes are not something that can be switched on/off
through a tunable. Does that mean that the best way to handle this is to
move the "typeattribute $1 can_relabelto_binary_policy;" out of the
seutil_relabelto_bin_policy() interface and make sure that whomever calls
that interface first sets this attribute?
Then, puppet would have the attribute set, but the effective permission
would still be "shielded" by the boolean...
Wkr,
Sven Vermeulen
On 8/13/2011 5:06 PM, Sven Vermeulen wrote:
> Hi guys,
>
> I wanted to all a call to seutil_relabelto_bin_policy() (through
> files_relabel_all_files) within puppet but only when the
> puppet_manage_all_files boolean is set.
>
> However, it seems that this is not allowed as the
> seutil_relabelto_bin_policy() interface would add an attribute to the given
> type using "typeattribute", which doesn't seem to work:
>
>
> /usr/bin/checkmodule: loading policy configuration from tmp/puppet.tmp
> puppet.te":142:ERROR 'syntax error' at token 'typeattribute' on line 8617:
> #line 142
> typeattribute puppet_t can_relabelto_binary_policy;
>
>
> I guess that attributes are not something that can be switched on/off
This is a limitation of conditional policy, and tunables are currently
implemented as Booleans/conditionals.
> through a tunable. Does that mean that the best way to handle this is to
> move the "typeattribute $1 can_relabelto_binary_policy;" out of the
> seutil_relabelto_bin_policy() interface and make sure that whomever calls
> that interface first sets this attribute?
>
> Then, puppet would have the attribute set, but the effective permission
> would still be "shielded" by the boolean...
Why would puppet need this access anyway? The binary policy should be
managed by semanage.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Tue, Aug 16, 2011 at 7:26 PM, Christopher J. PeBenito
<[email protected]> wrote:
[... Allow puppet to relabel all files, which includes binary policy files ...]
> Why would puppet need this access anyway? ?The binary policy should be managed by semanage.
True. As a matter of fact, I currently enclosed
files_relabel_all_files' contents without the seutil_ thingie.
We have a user that uses puppet extensively and he noticed that puppet
(which is SELinux-aware) is able to relabel files properly when they
are created or manipulated on the system. The current policy supports
that only for configuration file types, but for his installation that
isn't sufficient.
It now has relabel privileges for "file_type -policy_config_t
-security_file_type".
> Date: Sat, 13 Aug 2011 23:06:37 +0200
> From: sven.vermeulen at siphos.be
> To: refpolicy at oss.tresys.com
> Subject: [refpolicy] Calling typeattribute within a tunable_policy() is not allowed?
>
> Hi guys,
>
> I wanted to all a call to seutil_relabelto_bin_policy() (through
> files_relabel_all_files) within puppet but only when the
> puppet_manage_all_files boolean is set.
>
> However, it seems that this is not allowed as the
> seutil_relabelto_bin_policy() interface would add an attribute to the given
> type using "typeattribute", which doesn't seem to wo??rk:
>
>
> /usr/bin/checkmodule: loading policy configuration from tmp/puppet.tmp
> puppet.te":142:ERROR 'syntax error' at token 'typeattribute' on line 8617:
> #line 142
> typeattribute puppet_t can_relabelto_binary_policy;
>
>
> I guess that attributes are not something that can be switched on/off
> through a tunable.
Just a side note, so far the tunable is implemented as boolean, and the tunable_policy macro is expanded as if-else conditionals by m4, aiming to define some block of rules that could be switched on/off at runtime. However, the tunable and tunable_policy should take effect at module link/expand time - if the tunable if off, then related block of rules would not be linked and expanded at all.
As stated in policy_parse.y, only rules of AVRULE_AV and AVRULE_TYPE are allowed to be used in conditionals and all the rest would trigger "syntax error" as in your case:
cond_rule_def : cond_transition_def
{ $$ = $1; }
| cond_te_avtab_def
{ $$ = $1; }
| require_block
{ $$ = NULL; }
;
Moreover, we could further define some function to explicitly warn that some particular rule is not allowed in conditionals, see define_cond_filename_trans().
Cheers,
Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110818/3326dc73/attachment.html
On 8/18/2011 4:14 AM, HarryCiao wrote:
> > Date: Sat, 13 Aug 2011 23:06:37 +0200
> > From: sven.vermeulen at siphos.be
> > To: refpolicy at oss.tresys.com
> > Subject: [refpolicy] Calling typeattribute within a tunable_policy()
> is not allowed?
> >
> > Hi guys,
> >
> > I wanted to all a call to seutil_relabelto_bin_policy() (through
> > files_relabel_all_files) within puppet but only when the
> > puppet_manage_all_files boolean is set.
> >
> > However, it seems that this is not allowed as the
> > seutil_relabelto_bin_policy() interface would add an attribute to the
> given
> > type using "typeattribute", which doesn't seem to wo???? <#>rk:
> >
> >
> > /usr/bin/checkmodule: loading policy configuration from tmp/puppet.tmp
> > puppet.te":142:ERROR 'syntax error' at token 'typeattribute' on line
> 8617:
> > #line 142
> > ; typeattribute puppet_t can_relabelto_binary_policy;
> >
> >
> > I guess that attributes are not something that can be switched on/off
> > through a tunable.
>
> Just a side note, so far the tunable is implemented as boolean, and the
> tunable_policy macro is expanded as if-else conditionals by m4, aiming
> to define some block of rules that could be switched on/off at runtime.
> However, the tunable and tunable_policy should take effect at module
> link/expand time - if the tunable if off, then related block of rules
> would not be linked and expanded at all.
Yes, that is the reason I created tunables. The toolchain just hasn't
implemented that support yet. CIL will have this support, but thats not
done yet.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
> > > I guess that attributes are not something that can be switched on/off
> > > through a tunable.
> >
> > Just a side note, so far the tunable is implemented as boolean, and the
> > tunable_policy macro is expanded as if-else conditionals by m4, aiming
> > to define some block of rules that could be switched on/off at runtime.
> > However, the tunable and tunable_policy should take effect at module
> > link/expand time - if the tunable if off, then related block of rules
> > would not be linked and expanded at all.
>
> Yes, that is the reason I created tunables. The toolchain just hasn't
> implemented that support yet. CIL will have this support, but thats not
> done yet.
>
Hi Chris,
I just started to add such support for separating tunable from boolean in the toolchain, hope it would be useful for CIL as well.
Thanks,
Harry
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110819/2e9e22f2/attachment.html
On 08/18/11 21:44, HarryCiao wrote:
>
>> > > I guess that attributes are not something that can be switched on/off
>> > > through a tunable.
>> >
>> > Just a side note, so far the tunable is implemented as boolean, and the
>> > tunable_policy macro is expanded as if-else conditionals by m4, aiming
>> > to define some block of rules that could be switched on/off at runtime.
>> > However, the tunable and tunable_policy should take effect at module
>> > link/expand time - if the tunable if off, then related block of rules
>> > would not be linked and expanded at all.
>>
>> Yes, that is the reason I created tunables. The toolchain just hasn't
>> implemented that support yet. CIL will have this support, but thats not
>> done yet.
>
> I just started to add such support for separating tunable from boolean
> in the toolchain, hope it would be useful for CIL as well.
I think its already been implemented in CIL. You should talk to Steve
Lawrence about it.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 08/19/2011 08:04 AM, Christopher J. PeBenito wrote:
> On 08/18/11 21:44, HarryCiao wrote:
>>
>>>>> I guess that attributes are not something that can be switched on/off
>>>>> through a tunable.
>>>>
>>>> Just a side note, so far the tunable is implemented as boolean, and the
>>>> tunable_policy macro is expanded as if-else conditionals by m4, aiming
>>>> to define some block of rules that could be switched on/off at runtime.
>>>> However, the tunable and tunable_policy should take effect at module
>>>> link/expand time - if the tunable if off, then related block of rules
>>>> would not be linked and expanded at all.
>>>
>>> Yes, that is the reason I created tunables. The toolchain just hasn't
>>> implemented that support yet. CIL will have this support, but thats not
>>> done yet.
>>
>> I just started to add such support for separating tunable from boolean
>> in the toolchain, hope it would be useful for CIL as well.
>
> I think its already been implemented in CIL. You should talk to Steve
> Lawrence about it.
>
Chris is correct. Tunables have been implemented in CIL, allowing any
CIL statement to be used inside.
If you'd like to check it out, the CIL source is in a git repo:
git clone http://oss.tresys.com/git/cil.git
The CIL design is at the following link, but it's in the process of
being updated, so some statements (like tunables) are missing from the
design.
http://userspace.selinuxproject.org/trac/wiki/CilDesign
- Steve