From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Wed, 24 Aug 2011 08:23:44 -0400 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: References: , <4E53AEC0.7040009@tresys.com> Message-ID: <4E54ED50.3060802@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/24/11 01:39, HarryCiao wrote: >> 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. 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