[refpolicy] My patchset to test "Separating tunables from booleans"

[refpolicy] My patchset to test "Separating tunables from booleans"

[HarryCiao]

[-- Attachment #1.1: Type: text/plain, Size: 687 bytes --]


Hi,

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.

Thanks!

Harry
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 930 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-the-definition-of-the-boolean_policy-marcro.patch --]
[-- Type: text/x-patch, Size: 2257 bytes --]

From 77ce182184467d434281c5aba2c86c9ee1440a57 Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Sun, 21 Aug 2011 18:19:41 +0800
Subject: [refpolicy][v0 PATCH 1/4] Add the definition of the boolean_policy marcro.

boolean_policy macro would make use of boolean for runtime conditionals,
while tunable_policy macro would use tunable rather than boolean for
build-time conditionals.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 policy/support/loadable_module.spt |   38 +++++++++++++++++++++++++++++++----
 1 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/policy/support/loadable_module.spt b/policy/support/loadable_module.spt
index 1fe3ab3..251a5f9 100644
--- a/policy/support/loadable_module.spt
+++ b/policy/support/loadable_module.spt
@@ -120,10 +120,23 @@ define(`dflt_or_overr',`ifdef(`$1',$1,$2)')
 # This needs to be reworked so expressions
 # with parentheses can work.
 
-define(`declare_required_symbols',`
+define(`declare_required_booleans',`
 ifelse(regexp($1, `\w'), -1, `', `dnl
 bool regexp($1, `\(\w+\)', `\1');
-declare_required_symbols(regexp($1, `\w+\(.*\)', `\1'))dnl
+declare_required_booleans(regexp($1, `\w+\(.*\)', `\1'))dnl
+') dnl
+')
+
+##############################
+#
+# Extract tunables out of an expression.
+# This needs to be reworked so expressions
+# with parentheses can work.
+
+define(`declare_required_tunables',`
+ifelse(regexp($1, `\w'), -1, `', `dnl
+tunable regexp($1, `\(\w+\)', `\1');
+declare_required_tunables(regexp($1, `\w+\(.*\)', `\1'))dnl
 ') dnl
 ')
 
@@ -132,16 +145,31 @@ declare_required_symbols(regexp($1, `\w+\(.*\)', `\1'))dnl
 # Tunable declaration
 #
 define(`gen_tunable',`
-	bool $1 dflt_or_overr(`$1'_conf,$2);
+	tunable $1 dflt_or_overr(`$1'_conf,$2);
 ')
 
 ##############################
 #
-# Tunable policy handling
+# Build-time tunable policy handling
 #
 define(`tunable_policy',`
 	gen_require(`
-		declare_required_symbols(`$1')
+		declare_required_tunables(`$1')
+	')
+	if (`$1') {
+		$2
+	ifelse(`$3',`',`',`} else {
+		$3
+	')}
+')
+
+##############################
+#
+# Runtime boolean policy handling
+#
+define(`boolean_policy',`
+	gen_require(`
+		declare_required_booleans(`$1')
 	')
 	if (`$1') {
 		$2
-- 
1.7.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-user_ping-is-a-tunable-use-tunable_policy-for-it.patch --]
[-- Type: text/x-patch, Size: 1315 bytes --]

From 17b41b9ea0b92aad144a2b87174d7eb6f9c383ae Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Sun, 21 Aug 2011 19:38:46 +0800
Subject: [refpolicy][v0 PATCH 2/4] user_ping is a tunable, use tunable_policy for it.

user_ping is a tunable, use tunable_policy for it.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 policy/modules/admin/netutils.if |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/policy/modules/admin/netutils.if b/policy/modules/admin/netutils.if
index c6ca761..4164292 100644
--- a/policy/modules/admin/netutils.if
+++ b/policy/modules/admin/netutils.if
@@ -183,14 +183,13 @@ interface(`netutils_run_ping',`
 interface(`netutils_run_ping_cond',`
 	gen_require(`
 		type ping_t;
-		bool user_ping;
 	')
 
 	role $2 types ping_t;
 
-	if ( user_ping ) {
+	tunable_policy(`user_ping',`
 		netutils_domtrans_ping($1)
-	}
+	')
 ')
 
 ########################################
@@ -277,14 +276,13 @@ interface(`netutils_run_traceroute',`
 interface(`netutils_run_traceroute_cond',`
 	gen_require(`
 		type traceroute_t;
-		bool user_ping;
 	')
 
 	role $2 types traceroute_t;
 
-	if( user_ping ) {
+	tunable_policy(`user_ping',`
 		netutils_domtrans_traceroute($1)
-	}
+	')
 ')
 
 ########################################
-- 
1.7.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-mmap_low_allowed-is-a-tunable-use-tunable_policy-for.patch --]
[-- Type: text/x-patch, Size: 1049 bytes --]

From f50ea912509e70744f550208793bf38b1f9374e8 Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Mon, 22 Aug 2011 14:12:55 +0800
Subject: [refpolicy][v0 PATCH 3/4] mmap_low_allowed is a tunable, use tunable_policy for it

mmap_low_allowed is a tunable, use tunable_policy for it.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 policy/modules/kernel/domain.if |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/policy/modules/kernel/domain.if b/policy/modules/kernel/domain.if
index 6a1e4d1..899c9bf 100644
--- a/policy/modules/kernel/domain.if
+++ b/policy/modules/kernel/domain.if
@@ -1434,14 +1434,13 @@ interface(`domain_entry_file_spec_domtrans',`
 interface(`domain_mmap_low',`
 	gen_require(`
 		attribute mmap_low_domain_type;
-		bool mmap_low_allowed;
 	')
 
 	typeattribute $1 mmap_low_domain_type;
 
-	if ( mmap_low_allowed ) {
+	tunable_policy(`mmap_low_allowed',`
 		allow $1 self:memprotect mmap_zero;
-	}
+	')
 ')
 
 ########################################
-- 
1.7.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-secure_mode_insmod-is-a-boolean-use-boolean_policy-f.patch --]
[-- Type: text/x-patch, Size: 1704 bytes --]

From 49e415efe1cf7d2a4dda66a1246b4cf73031829c Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Mon, 22 Aug 2011 14:15:52 +0800
Subject: [refpolicy][v0 PATCH 4/4] secure_mode_insmod is a boolean, use boolean_policy for it.

secure_mode_insmod is a boolean, use boolean_policy for it.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 policy/modules/system/modutils.if |    8 ++------
 policy/modules/system/modutils.te |    8 ++------
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/policy/modules/system/modutils.if b/policy/modules/system/modutils.if
index 9c0faab..6e7e0ef 100644
--- a/policy/modules/system/modutils.if
+++ b/policy/modules/system/modutils.if
@@ -152,13 +152,9 @@ interface(`modutils_domtrans_insmod_uncond',`
 ## </param>
 #
 interface(`modutils_domtrans_insmod',`
-	gen_require(`
-		bool secure_mode_insmod;
-	')
-
-	if (!secure_mode_insmod) {
+	boolean_policy(`!secure_mode_insmod',`
 		modutils_domtrans_insmod_uncond($1)
-	}
+	')
 ')
 
 ########################################
diff --git a/policy/modules/system/modutils.te b/policy/modules/system/modutils.te
index da014ed..143112a 100644
--- a/policy/modules/system/modutils.te
+++ b/policy/modules/system/modutils.te
@@ -1,9 +1,5 @@
 policy_module(modutils, 1.11.0)
 
-gen_require(`
-	bool secure_mode_insmod;
-')
-
 ########################################
 #
 # Declarations
@@ -178,9 +174,9 @@ userdom_use_user_terminals(insmod_t)
 
 userdom_dontaudit_search_user_home_dirs(insmod_t)
 
-if( ! secure_mode_insmod ) {
+boolean_policy(`!secure_mode_insmod',`
 	kernel_domtrans_to(insmod_t, insmod_exec_t)
-}
+')
 
 optional_policy(`
 	alsa_domtrans(insmod_t)
-- 
1.7.0.4

[refpolicy] My patchset to test "Separating tunables from booleans"

[HarryCiao]

Hi,

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.

Thanks!

Harry
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-the-definition-of-the-boolean_policy-marcro.patch
Type: text/x-patch
Size: 2257 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-user_ping-is-a-tunable-use-tunable_policy-for-it.patch
Type: text/x-patch
Size: 1315 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-mmap_low_allowed-is-a-tunable-use-tunable_policy-for.patch
Type: text/x-patch
Size: 1049 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-secure_mode_insmod-is-a-boolean-use-boolean_policy-f.patch
Type: text/x-patch
Size: 1704 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment-0003.bin 

Re: [refpolicy] My patchset to test "Separating tunables from booleans"

[Christopher J. PeBenito]

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.

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.

-- 
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.

[refpolicy] My patchset to test "Separating tunables from booleans"

[Christopher J. PeBenito]

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.

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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

RE: [refpolicy] My patchset to test "Separating tunables from booleans"

[HarryCiao]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]


Hi Chris,

> 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.


> 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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 4319 bytes --]

[refpolicy] My patchset to test "Separating tunables from booleans"

[HarryCiao]

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 

Re: [refpolicy] My patchset to test "Separating tunables from booleans"

[Christopher J. PeBenito]

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.

[refpolicy] My patchset to test "Separating tunables from booleans"

[Christopher J. PeBenito]

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

RE: [refpolicy] My patchset to test "Separating tunables from booleans"

[HarryCiao]

[-- Attachment #1: Type: text/plain, Size: 6150 bytes --]


Hi Chris,

> Date: Wed, 24 Aug 2011 08:23:44 -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/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?
> 

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-time, 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(),
> > 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.
> 

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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 7552 bytes --]

[refpolicy] My patchset to test "Separating tunables from booleans"

[HarryCiao]

Hi Chris,

> Date: Wed, 24 Aug 2011 08:23:44 -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/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?
> 

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-time, 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(),
> > 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.
> 

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 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/20110825/80f9e295/attachment.html 

Re: [refpolicy] My patchset to test "Separating tunables from booleans"

[Christopher J. PeBenito]

On 08/24/11 23:10, HarryCiao wrote:
> Hi Chris,
> 
>> Date: Wed, 24 Aug 2011 08:23:44 -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/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 wo uld 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?
>>
> 
> 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.

Yes I know that.  Please give an example of declaring a tunable and
making a tunable block, in the raw policy.


>> >> 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.
>>
> 
> 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().

I still want this to error out.  I'll fix the policy.

-- 
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.

[refpolicy] My patchset to test "Separating tunables from booleans"

[Christopher J. PeBenito]

On 08/24/11 23:10, HarryCiao wrote:
> Hi Chris,
> 
>> Date: Wed, 24 Aug 2011 08:23:44 -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/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 wo uld 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?
>>
> 
> 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.

Yes I know that.  Please give an example of declaring a tunable and
making a tunable block, in the raw policy.


>> >> 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.
>>
> 
> 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().

I still want this to error out.  I'll fix the policy.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com