From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7OCNkfB031395 for ; Wed, 24 Aug 2011 08:23:46 -0400 Received: from exchange10.columbia.tresys.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p7OCNjet017768 for ; Wed, 24 Aug 2011 12:23:45 GMT Message-ID: <4E54ED50.3060802@tresys.com> Date: Wed, 24 Aug 2011 08:23:44 -0400 From: "Christopher J. PeBenito" MIME-Version: 1.0 To: HarryCiao CC: , Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" References: ,<4E53AEC0.7040009@tresys.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 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