|
Hi Chris,
> Date: Tue, 23 Aug 2011 09:44:32 -0400
> From: cpebenito@xxxxxxxxxx > To: harrytaurus2002@xxxxxxxxxxx > CC: refpolicy@xxxxxxxxxxxxxxx; selinux@xxxxxxxxxxxxx > 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 ide ntifier 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. > 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 warnin! g 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) 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. Thanks, Harry > > -- > 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@xxxxxxxxxxxxx with > the word! s "unsubscribe selinux" without quotes as the message. |
