Re: [refpolicy] My patchset to test "Separating tunables from booleans"

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On 08/24/11 01:39, HarryCiao wrote:
>> Date: Tue, 23 Aug 2011 09:44:32 -0400
>> From: cpebenito@tresys.com
>> To: harrytaurus2002@hotmail.com
>> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov
>> Subject: Re: [refpolicy] My patchset to test "Separating tunables from
> booleans"
>>
>> On 08/23/11 06:27, HarryCiao wrote:
>> > This is the refpolicy patchset to test along with new toolchain feature
>> > of separating tunables from booleans, generally speaking a "tunable"
>> > keyword is introduced and made use of by tunable_policy(), whereas a new
>> > boolean_policy() macro would make use of the "bool" keyword.
>> >
>> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit
>> > would be set in the newly added member of flags in the cond_bool_datum_t
>> > structure.
>> >
>> > Once the new toolchain feature is welcomed and merged, we could change
>> > refpolicy to shrink policy.X size significantly.
>> >
>> > Any comments or suggestions as for how to better this new toolchain
>> > feature are greatly welcomed.
>>
>> To make sure I understand correctly, a tunable block will have the same
>> token in the raw policy as runtime conditional blocks? e.g.
>>
>> tunable foo false;
>> if (foo) {
>> ....
>> }
>>
>> If tunable blocks use the same token, I think Refpolicy would just drop
>> the tunable_policy() macro.
>>
> 
> The tunable identifier won't be written to policy.X.
> 
> During link, the logically "true" branch of its if-else branches would
> be treated as permanent rules and append to the end of decl->avrules
> list, resulting in expanded and registered into te_avtab hashtab.
> 
> As for boolean, the identifier would be written to policy.X and both
> if-else branches would be expanded and registered to te_cond_avtab
> hashtab, so is the cond_node_t for boolean.
> 
> Both tunable and boolean identifier would share the same
> cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been
> introduced to differentiate them, which would be set only when the
> identifier is defined/required by "tunable" keyword.
> 
> So both "tunable" and "bool" keywords would have to be supported by
> toolchain, so are tunable_policy() and boolean_policy() macros.

I don't understand why you say boolean_policy() and tunable_policy()
macros are needed.  Based on the implementation in your test patch, they
are not different in the raw policy.  Are you suggesting it for the
automatic bool/tunable gen_require block generation?

>> There are no examples of this in Refpolicy, but can you mix Booleans and
>> tunables in an expression? e.g.
>>
>> tunable foo true;
>> boolean bar true;
>> if (foo || bar) {
>> ....
>> }
>>
>> I'd say its not a requirement, I'm just trying to make sure I understand
>> the features.
> 
> Yes, there is just one example in refpolicy. As showed in my test
> results, the pppd_can_ismod identifier is declared by gen_tunable(),
> however, it is used along with secure_mode_insmod boolean in ppp.te.
> 
> Such hybird expression is not welcomed I guess, so some warning
> information would be printed out during link. In my test result, the
> secure_mode_insmod would be blamed, since it's declared by gen_bool()
> but used in tunable_policy(), which would require it as a tunable.
> (That's also why until all p_bools.table from all modules have been
> copied during link could we finally determine if a cond_bool_datum_t is
> indeed a boolean or tunable)

The reason it has to be like this is because nested conditional policy
is not supported.  Otherwise it would be written like:

tunable_policy(`pppd_can_insmod',`
	modutils_domtrans_insmod(pppd_t)
')
		

> For such situation since it would be difficult to correctly remove the
> cond_expr_t for tunables and related operators, I've decided to
> transform tunable to boolean(just by cleaning the TUNABLE flag bit) then
> the whole cond_node_t would be treated as normal.

I think it would be better to error.  Then the user can decided what to
do about it.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.