From: harrytaurus2002@hotmail.com (HarryCiao) Date: Wed, 24 Aug 2011 05:39:48 +0000 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: <4E53AEC0.7040009@tresys.com> References: , <4E53AEC0.7040009@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Chris, > Date: Tue, 23 Aug 2011 09:44:32 -0400 > From: cpebenito at tresys.com > To: harrytaurus2002 at hotmail.com > CC: refpolicy at oss1.tresys.com; selinux at 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. > 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) 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 at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/58dca7ea/attachment.html