|
Hi Chris,
> Date: Wed, 24 Aug 2011 08:23:44 -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/24/11 01:39, HarryCiao wrote: > >> 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) { > >&! gt; .... > >> } > >> > >> If tunab le 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/requir! ed 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? > boolean_policy() and tunable_policy() are not for raw policy, their goal is to tell toolchain the difference between a boolean and a tunable, and that's all. Then toolchain would handle boolean and tunable in different manner, for tunable, no identifiers written to policy.X and the logically true branch of its conditional would be expanded to policy.X permanently. In a nutshell, booleans provide the capability to switch on/off blocks of rules at run-tim! e, whereas tunable are more about "once-and-for-all" situations: once the system administrator figures out the desirable branch in a tunable's conditional, he/she could set the tuanble's default value and very likely won't change it much, in such case only the effective branch of a tunable conditional should be written to raw policy. The automatic gen_require block generation is good to have, doesn't it? > >> 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(), > > ho! wever, 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 > &g t; 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. > I understand this is for working around the need to nest tunable with tunable/boolean. Since pppd_can_insmod has been used with secure_mode_insmod in current refpolicy, error out would break the build, that's why I've chosen to just put some information. BTW, in this situation the toolchain would bump the pppd_can_insmod from tunable to boolean(by clearing it TUNABLE flag), then the policy writer won't even bother to change the declaration of pppd_can_insmod from gen_tunable() to gen_bool(). 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 words "unsubscribe selinux" without quotes as the message. |
