Use of optional_policy in templates (compiler bug or feature?)

Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

Is it legitimate to define a type within an optional_policy within a  
template?

I ask because there are a number of compile issues with policy that  
look like:

template(`wm_domain_template',`
...
         optional_policy(`
                 dbus_system_bus_client_template($1_wm,$1_wm_t)
# does not compile
#               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
         ')
...
')

Looking at the checkmodule source, it looks like type declarations  
declared within optionals are popped off the symbol stack in  
end_optional but left in the symbol table. These symbols later fail an  
is_id_in_scope test and generate an 'duplicate declaration of type/ 
attribute'.

I think this is related to:
http://oss.tresys.com/projects/refpolicy/ticket/43

and earlier complaints about this behavior in the X policy from Dan  
and Eamon in June/July.
http://www.nsa.gov/SeLinux/list-archive/0806/thread_body18.cfm

I'm running libsepol-2.0.33 which has the fix in the above thread.

joe

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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Christopher J. PeBenito]

On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
> Is it legitimate to define a type within an optional_policy within a  
> template?

Yes.

> I ask because there are a number of compile issues with policy that  
> look like:
> 
> template(`wm_domain_template',`
> ...
>          optional_policy(`
>                  dbus_system_bus_client_template($1_wm,$1_wm_t)
> # does not compile
> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>          ')
> ...
> ')

I can't reproduce this by just adding it to a random module; there are
likely more factors that just the above template calls.

> Looking at the checkmodule source, it looks like type declarations  
> declared within optionals are popped off the symbol stack in  
> end_optional but left in the symbol table. These symbols later fail an  
> is_id_in_scope test and generate an 'duplicate declaration of type/ 
> attribute'.
> 
> I think this is related to:
> http://oss.tresys.com/projects/refpolicy/ticket/43
> 
> and earlier complaints about this behavior in the X policy from Dan  
> and Eamon in June/July.
> http://www.nsa.gov/SeLinux/list-archive/0806/thread_body18.cfm
> 
> I'm running libsepol-2.0.33 which has the fix in the above thread.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:

> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>> Is it legitimate to define a type within an optional_policy within a
>> template?
>
> Yes.
>
>> I ask because there are a number of compile issues with policy that
>> look like:
>>
>> template(`wm_domain_template',`
>> ...
>>         optional_policy(`
>>                 dbus_system_bus_client_template($1_wm,$1_wm_t)
>> # does not compile
>> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>         ')
>> ...
>> ')
>
> I can't reproduce this by just adding it to a random module; there are
> likely more factors that just the above template calls.

Using stock Fedora targeted policy:

policy_module(swo,1.0.0)

userdom_unpriv_user_template(swo)
dbus_chat_user_bus(swo,swo_t)

joe



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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Christopher J. PeBenito]

On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
> 
> > On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
> >> Is it legitimate to define a type within an optional_policy within a
> >> template?
> >
> > Yes.
> >
> >> I ask because there are a number of compile issues with policy that
> >> look like:
> >>
> >> template(`wm_domain_template',`
> >> ...
> >>         optional_policy(`
> >>                 dbus_system_bus_client_template($1_wm,$1_wm_t)
> >> # does not compile
> >> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
> >>         ')
> >> ...
> >> ')
> >
> > I can't reproduce this by just adding it to a random module; there are
> > likely more factors that just the above template calls.
> 
> Using stock Fedora targeted policy:
> 
> policy_module(swo,1.0.0)
> 
> userdom_unpriv_user_template(swo)
> dbus_chat_user_bus(swo,swo_t)

Well this is a weird case, because you have this situation:

optional {
	# optionally declare the type
	# from userdom_unpriv_user_template(swo)
	type swo_dbusd_t;
}

# unconditionally require the type for this module
# from dbus_chat_user_bus(swo,swo_t)
require {
	type swo_dbusd_t;
}


but even if you make the second interface call optional too, you'll
still get the compile error.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Oct 16, 2008, at 7:49 AM, Christopher J. PeBenito wrote:

> On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
>> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
>>
>>> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>>>> Is it legitimate to define a type within an optional_policy  
>>>> within a
>>>> template?
>>>
>>> Yes.
>>>
>>>> I ask because there are a number of compile issues with policy that
>>>> look like:
>>>>
>>>> template(`wm_domain_template',`
>>>> ...
>>>>        optional_policy(`
>>>>                dbus_system_bus_client_template($1_wm,$1_wm_t)
>>>> # does not compile
>>>> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>>>        ')
>>>> ...
>>>> ')
>>>
>>> I can't reproduce this by just adding it to a random module; there  
>>> are
>>> likely more factors that just the above template calls.
>>
>> Using stock Fedora targeted policy:
>>
>> policy_module(swo,1.0.0)
>>
>> userdom_unpriv_user_template(swo)
>> dbus_chat_user_bus(swo,swo_t)
>
> Well this is a weird case, because you have this situation:
>
> optional {
> 	# optionally declare the type
> 	# from userdom_unpriv_user_template(swo)
> 	type swo_dbusd_t;
> }
>
> # unconditionally require the type for this module
> # from dbus_chat_user_bus(swo,swo_t)
> require {
> 	type swo_dbusd_t;
> }
>
>
> but even if you make the second interface call optional too, you'll
> still get the compile error.

Weird wrong or weird corner case that ought to work?

joe




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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joshua Brindle]

Joe Nall wrote:
>
> On Oct 16, 2008, at 7:49 AM, Christopher J. PeBenito wrote:
>
>> On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
>>> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
>>>
>>>> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>>>>> Is it legitimate to define a type within an optional_policy within a
>>>>> template?
>>>>
>>>> Yes.
>>>>
>>>>> I ask because there are a number of compile issues with policy that
>>>>> look like:
>>>>>
>>>>> template(`wm_domain_template',`
>>>>> ...
>>>>>        optional_policy(`
>>>>>                dbus_system_bus_client_template($1_wm,$1_wm_t)
>>>>> # does not compile
>>>>> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>>>>        ')
>>>>> ...
>>>>> ')
>>>>
>>>> I can't reproduce this by just adding it to a random module; there are
>>>> likely more factors that just the above template calls.
>>>
>>> Using stock Fedora targeted policy:
>>>
>>> policy_module(swo,1.0.0)
>>>
>>> userdom_unpriv_user_template(swo)
>>> dbus_chat_user_bus(swo,swo_t)
>>
>> Well this is a weird case, because you have this situation:
>>
>> optional {
>>     # optionally declare the type
>>     # from userdom_unpriv_user_template(swo)
>>     type swo_dbusd_t;
>> }
>>
>> # unconditionally require the type for this module
>> # from dbus_chat_user_bus(swo,swo_t)
>> require {
>>     type swo_dbusd_t;
>> }
>>
>>
>> but even if you make the second interface call optional too, you'll
>> still get the compile error.
>
> Weird wrong or weird corner case that ought to work?
>

Weird unsupported. It was thought non-trivial to deterministically 
enable optionals in cases like this.


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Oct 16, 2008, at 9:50 AM, Joshua Brindle wrote:

> Joe Nall wrote:
>>
>> On Oct 16, 2008, at 7:49 AM, Christopher J. PeBenito wrote:
>>
>>> On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
>>>> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
>>>>
>>>>> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>>>>>> Is it legitimate to define a type within an optional_policy  
>>>>>> within a
>>>>>> template?
>>>>>
>>>>> Yes.
>>>>>
>>>>>> I ask because there are a number of compile issues with policy  
>>>>>> that
>>>>>> look like:
>>>>>>
>>>>>> template(`wm_domain_template',`
>>>>>> ...
>>>>>>       optional_policy(`
>>>>>>               dbus_system_bus_client_template($1_wm,$1_wm_t)
>>>>>> # does not compile
>>>>>> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>>>>>       ')
>>>>>> ...
>>>>>> ')
>>>>>
>>>>> I can't reproduce this by just adding it to a random module;  
>>>>> there are
>>>>> likely more factors that just the above template calls.
>>>>
>>>> Using stock Fedora targeted policy:
>>>>
>>>> policy_module(swo,1.0.0)
>>>>
>>>> userdom_unpriv_user_template(swo)
>>>> dbus_chat_user_bus(swo,swo_t)
>>>
>>> Well this is a weird case, because you have this situation:
>>>
>>> optional {
>>>    # optionally declare the type
>>>    # from userdom_unpriv_user_template(swo)
>>>    type swo_dbusd_t;
>>> }
>>>
>>> # unconditionally require the type for this module
>>> # from dbus_chat_user_bus(swo,swo_t)
>>> require {
>>>    type swo_dbusd_t;
>>> }
>>>
>>>
>>> but even if you make the second interface call optional too, you'll
>>> still get the compile error.
>>
>> Weird wrong or weird corner case that ought to work?
>>
>
> Weird unsupported. It was thought non-trivial to deterministically  
> enable optionals in cases like this.

So all optional policy in templates using a given derived type have to  
be in the same optional block?

Dan took the per role expansion out of the core policy in fedora and  
put the per role templates in an optional blocks in role based .te  
files. This tickles this 'Weird unsupported' corner of the compiler  
repeatedly. The weird thing to me is that it mostly works. The big  
exceptions are in the X and dbus policies which have all sorts of  
nested optional interactions (just like the code).

joe



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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Daniel J Walsh]

Joshua Brindle wrote:
> Joe Nall wrote:
>>
>> On Oct 16, 2008, at 7:49 AM, Christopher J. PeBenito wrote:
>>
>>> On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
>>>> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
>>>>
>>>>> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>>>>>> Is it legitimate to define a type within an optional_policy within a
>>>>>> template?
>>>>>
>>>>> Yes.
>>>>>
>>>>>> I ask because there are a number of compile issues with policy that
>>>>>> look like:
>>>>>>
>>>>>> template(`wm_domain_template',`
>>>>>> ...
>>>>>>        optional_policy(`
>>>>>>                dbus_system_bus_client_template($1_wm,$1_wm_t)
>>>>>> # does not compile
>>>>>> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>>>>>        ')
>>>>>> ...
>>>>>> ')
>>>>>
>>>>> I can't reproduce this by just adding it to a random module; there are
>>>>> likely more factors that just the above template calls.
>>>>
>>>> Using stock Fedora targeted policy:
>>>>
>>>> policy_module(swo,1.0.0)
>>>>
>>>> userdom_unpriv_user_template(swo)
>>>> dbus_chat_user_bus(swo,swo_t)
>>>
>>> Well this is a weird case, because you have this situation:
>>>
>>> optional {
>>>     # optionally declare the type
>>>     # from userdom_unpriv_user_template(swo)
>>>     type swo_dbusd_t;
>>> }
>>>
>>> # unconditionally require the type for this module
>>> # from dbus_chat_user_bus(swo,swo_t)
>>> require {
>>>     type swo_dbusd_t;
>>> }
>>>
>>>
>>> but even if you make the second interface call optional too, you'll
>>> still get the compile error.
>>
>> Weird wrong or weird corner case that ought to work?
>>
> 
> Weird unsupported. It was thought non-trivial to deterministically
> enable optionals in cases like this.
> 
> 
> -- 
> 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.
These cases happen to me all the time, and I end up having to code
around them in weird ways.  As the policy gets more complicated and
interactions become more complex, we are going to see the compiler blow up.

dbus, xserver, confined users, are all causing interesting failure modes.



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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Oct 20, 2008, at 1:19 PM, Daniel J Walsh wrote:

> Joshua Brindle wrote:
>> Joe Nall wrote:
>>>
>>> On Oct 16, 2008, at 7:49 AM, Christopher J. PeBenito wrote:
>>>
>>>> On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
>>>>> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
>>>>>
>>>>>> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>>>>>>> Is it legitimate to define a type within an optional_policy  
>>>>>>> within a
>>>>>>> template?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>> I ask because there are a number of compile issues with policy  
>>>>>>> that
>>>>>>> look like:
>>>>>>>
>>>>>>> template(`wm_domain_template',`
>>>>>>> ...
>>>>>>>       optional_policy(`
>>>>>>>               dbus_system_bus_client_template($1_wm,$1_wm_t)
>>>>>>> # does not compile
>>>>>>> #               dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>>>>>>       ')
>>>>>>> ...
>>>>>>> ')
>>>>>>
>>>>>> I can't reproduce this by just adding it to a random module;  
>>>>>> there are
>>>>>> likely more factors that just the above template calls.
>>>>>
>>>>> Using stock Fedora targeted policy:
>>>>>
>>>>> policy_module(swo,1.0.0)
>>>>>
>>>>> userdom_unpriv_user_template(swo)
>>>>> dbus_chat_user_bus(swo,swo_t)
>>>>
>>>> Well this is a weird case, because you have this situation:
>>>>
>>>> optional {
>>>>    # optionally declare the type
>>>>    # from userdom_unpriv_user_template(swo)
>>>>    type swo_dbusd_t;
>>>> }
>>>>
>>>> # unconditionally require the type for this module
>>>> # from dbus_chat_user_bus(swo,swo_t)
>>>> require {
>>>>    type swo_dbusd_t;
>>>> }
>>>>
>>>>
>>>> but even if you make the second interface call optional too, you'll
>>>> still get the compile error.
>>>
>>> Weird wrong or weird corner case that ought to work?
>>>
>>
>> Weird unsupported. It was thought non-trivial to deterministically
>> enable optionals in cases like this.
>>
>>
>> -- 
>> 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.
> These cases happen to me all the time, and I end up having to code
> around them in weird ways.  As the policy gets more complicated and
> interactions become more complex, we are going to see the compiler  
> blow up.
>
> dbus, xserver, confined users, are all causing interesting failure  
> modes.

I'm really struggling to get our mls X policy to work around this  
issue. I have to rebuild the base policy for every change because the  
change has to be in the optional. blagh.

joe


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Eamon Walsh]

Joe Nall wrote:
> I'm really struggling to get our mls X policy to work around this  
> issue. I have to rebuild the base policy for every change because the  
> change has to be in the optional. blagh.
>
> joe
>   

We took a look at this and applied the following patch to checkmodule:

diff --git a/checkpolicy/module_compiler.c b/checkpolicy/module_compiler.c
index 36d20be..c8a6d05 100644
--- a/checkpolicy/module_compiler.c
+++ b/checkpolicy/module_compiler.c
@@ -904,8 +904,7 @@ static int require_type_or_attribute(int pass, unsigned char isattr)
 			return -1;
 		}
 	case -2:{
-			yyerror("duplicate declaration of type/attribute");
-			return -1;
+			return 0;
 		}
 	case -1:{
 			yyerror("could not require type/attribute here");



The magic -2 value is documented at the top of require_symbol() as
meaning "duplicate declaration", however, in the bowels of the function
(module_compiler.c line 628) this is contradicted by the statement
"previous declaration was not in scope or had a mismatched
type/attribute."  So I think the error message touched in the above
patch is wrong, or at least not always correct.

Anyway, the return -2 on line 628 is the case encountered by Joe's test
code.  And in fact applying the above patch changes the error to:

/home/ewalsh/git/selinux/checkpolicy/checkmodule:  loading policy configuration from tmp/swo.tmp
swo.te":4:ERROR 'type swo_dbusd_t is not within scope' at token ';' on line 77949:
        allow swo_t swo_dbusd_t:dbus send_msg;
#line 4
/home/ewalsh/git/selinux/checkpolicy/checkmodule:  error(s) encountered while parsing configuration


So perhaps we could do something like go back and promote type
declarations in optional blocks into the containing scope when a require
is encountered further along?  Josh?


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Stephen Smalley]

On Mon, 2008-10-20 at 19:52 -0400, Eamon Walsh wrote:
> Joe Nall wrote:
> > I'm really struggling to get our mls X policy to work around this  
> > issue. I have to rebuild the base policy for every change because the  
> > change has to be in the optional. blagh.
> >
> > joe
> >   
> 
> We took a look at this and applied the following patch to checkmodule:
> 
> diff --git a/checkpolicy/module_compiler.c
> b/checkpolicy/module_compiler.c
> index 36d20be..c8a6d05 100644
> --- a/checkpolicy/module_compiler.c
> +++ b/checkpolicy/module_compiler.c
> @@ -904,8 +904,7 @@ static int require_type_or_attribute(int pass,
> unsigned char isattr)
>  			return -1;
>  		}
>  	case -2:{
> -			yyerror("duplicate declaration of type/attribute");
> -			return -1;
> +			return 0;
>  		}
>  	case -1:{
>  			yyerror("could not require type/attribute here");
> 
> 
> 
> The magic -2 value is documented at the top of require_symbol() as
> meaning "duplicate declaration", however, in the bowels of the
> function
> (module_compiler.c line 628) this is contradicted by the statement
> "previous declaration was not in scope or had a mismatched
> type/attribute."  So I think the error message touched in the above
> patch is wrong, or at least not always correct.
> 
> Anyway, the return -2 on line 628 is the case encountered by Joe's
> test
> code.  And in fact applying the above patch changes the error to:
> 
> /home/ewalsh/git/selinux/checkpolicy/checkmodule:  loading policy
> configuration from tmp/swo.tmp
> swo.te":4:ERROR 'type swo_dbusd_t is not within scope' at token ';' on
> line 77949:
>         allow swo_t swo_dbusd_t:dbus send_msg;
> #line 4
> /home/ewalsh/git/selinux/checkpolicy/checkmodule:  error(s)
> encountered while parsing configuration
> 
> 
> So perhaps we could do something like go back and promote type
> declarations in optional blocks into the containing scope when a
> require
> is encountered further along?  Josh?

What's wrong with just falling through in the require-follows-decl case
and adding the avrule decl id to the scope datum such that later
is_id_in_scope() checks succeed?  With this patch applied, the trivial
sample module posted by Joe builds for me, and can be inserted w/o
error.  I did notice however that I could also get it to build w/o
changing checkmodule by reversing the order of the interface calls there
- not sure if that workaround is usable in the original case that
triggered this bug report.

diff --git a/libsepol/src/policydb.c b/libsepol/src/policydb.c
index d623343..be9c334 100644
--- a/libsepol/src/policydb.c
+++ b/libsepol/src/policydb.c
@@ -1273,9 +1273,6 @@ int symtab_insert(policydb_t * pol, uint32_t sym,
 		}
 	} else if (scope_datum->scope == SCOPE_REQ && scope == SCOPE_DECL) {
 		scope_datum->scope = SCOPE_DECL;
-	} else if (scope_datum->scope != scope) {
-		/* This only happens in DECL then REQUIRE case, which is handled by caller */
-		return -2;
 	}
 
 	/* search through the pre-existing list to avoid adding duplicates */

-- 
Stephen Smalley
National Security Agency


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:

>   I did notice however that I could also get it to build w/o
> changing checkmodule by reversing the order of the interface calls  
> there
> - not sure if that workaround is usable in the original case that
> triggered this bug report.


Arranging modules in the proper order becomes increasingly difficult  
as module interaction grows. I finally de-optioned the X policy in  
fedora since it is in base so get our additions to compile. Patch  
included for reference.

Making the compiler gracefully deal with options would really be  
appreciated. I could see the issue in the compiler code, but the right  
fix wasn't obvious.

joe

diff -up serefpolicy-3.5.10/policy/modules/system/userdomain.if.orig  
serefpolicy-3.5.10/policy/modules/system/userdomain.if
--- serefpolicy-3.5.10/policy/modules/system/userdomain.if.orig  
2008-10-20 14:14:37.000000000 -0500
+++ serefpolicy-3.5.10/policy/modules/system/userdomain.if       
2008-10-20 14:27:37.000000000 -0500
  #######################################
@@ -658,9 +660,7 @@ template(`userdom_common_user_template',

         userdom_exec_generic_pgms_template($1)

-       optional_policy(`
-               userdom_xwindows_client_template($1)
-       ')
+       userdom_xwindows_client_template($1)

         ##############################
         #


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Stephen Smalley]

On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
> 
> >   I did notice however that I could also get it to build w/o
> > changing checkmodule by reversing the order of the interface calls  
> > there
> > - not sure if that workaround is usable in the original case that
> > triggered this bug report.
> 
> 
> Arranging modules in the proper order becomes increasingly difficult  
> as module interaction grows. I finally de-optioned the X policy in  
> fedora since it is in base so get our additions to compile. Patch  
> included for reference.
> 
> Making the compiler gracefully deal with options would really be  
> appreciated. I could see the issue in the compiler code, but the right  
> fix wasn't obvious.

Does the patch I posted fix your problem?

> joe
> 
> diff -up serefpolicy-3.5.10/policy/modules/system/userdomain.if.orig  
> serefpolicy-3.5.10/policy/modules/system/userdomain.if
> --- serefpolicy-3.5.10/policy/modules/system/userdomain.if.orig  
> 2008-10-20 14:14:37.000000000 -0500
> +++ serefpolicy-3.5.10/policy/modules/system/userdomain.if       
> 2008-10-20 14:27:37.000000000 -0500
>   #######################################
> @@ -658,9 +660,7 @@ template(`userdom_common_user_template',
> 
>          userdom_exec_generic_pgms_template($1)
> 
> -       optional_policy(`
> -               userdom_xwindows_client_template($1)
> -       ')
> +       userdom_xwindows_client_template($1)
> 
>          ##############################
>          #
-- 
Stephen Smalley
National Security Agency


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Stephen Smalley]

On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
> > On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
> > 
> > >   I did notice however that I could also get it to build w/o
> > > changing checkmodule by reversing the order of the interface calls  
> > > there
> > > - not sure if that workaround is usable in the original case that
> > > triggered this bug report.
> > 
> > 
> > Arranging modules in the proper order becomes increasingly difficult  
> > as module interaction grows. I finally de-optioned the X policy in  
> > fedora since it is in base so get our additions to compile. Patch  
> > included for reference.
> > 
> > Making the compiler gracefully deal with options would really be  
> > appreciated. I could see the issue in the compiler code, but the right  
> > fix wasn't obvious.
> 
> Does the patch I posted fix your problem?

And by fix, I mean not only does it allow you to build the policy but
does it yield the expected final kernel policy (i.e. look at the
policy.N file via apol and check that you are getting the expected types
and rules in the final policy).

-- 
Stephen Smalley
National Security Agency


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
>   
>> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
>>     
>>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
>>>
>>>       
>>>>   I did notice however that I could also get it to build w/o
>>>> changing checkmodule by reversing the order of the interface calls  
>>>> there
>>>> - not sure if that workaround is usable in the original case that
>>>> triggered this bug report.
>>>>         
>>> Arranging modules in the proper order becomes increasingly difficult  
>>> as module interaction grows. I finally de-optioned the X policy in  
>>> fedora since it is in base so get our additions to compile. Patch  
>>> included for reference.
>>>
>>> Making the compiler gracefully deal with options would really be  
>>> appreciated. I could see the issue in the compiler code, but the right  
>>> fix wasn't obvious.
>>>       
>> Does the patch I posted fix your problem?
>>     
>
> And by fix, I mean not only does it allow you to build the policy but
> does it yield the expected final kernel policy (i.e. look at the
> policy.N file via apol and check that you are getting the expected types
> and rules in the final policy).
>   

I just worry that allowing situations like this will cause the linker to 
not properly (or deterministically) enable optional blocks. That is why 
we require everything be scoped locally to be used. We have, however, 
made changes to the linker algorithm since the original module codebase 
so it might have gotten better, but I don't think anyone has sat down 
and figured out exactly which cases can be required and which ones may 
be prevented.


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Stephen Smalley]

On Wed, 2008-10-22 at 13:42 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
> >   
> >> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
> >>     
> >>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
> >>>
> >>>       
> >>>>   I did notice however that I could also get it to build w/o
> >>>> changing checkmodule by reversing the order of the interface calls  
> >>>> there
> >>>> - not sure if that workaround is usable in the original case that
> >>>> triggered this bug report.
> >>>>         
> >>> Arranging modules in the proper order becomes increasingly difficult  
> >>> as module interaction grows. I finally de-optioned the X policy in  
> >>> fedora since it is in base so get our additions to compile. Patch  
> >>> included for reference.
> >>>
> >>> Making the compiler gracefully deal with options would really be  
> >>> appreciated. I could see the issue in the compiler code, but the right  
> >>> fix wasn't obvious.
> >>>       
> >> Does the patch I posted fix your problem?
> >>     
> >
> > And by fix, I mean not only does it allow you to build the policy but
> > does it yield the expected final kernel policy (i.e. look at the
> > policy.N file via apol and check that you are getting the expected types
> > and rules in the final policy).
> >   
> 
> I just worry that allowing situations like this will cause the linker to 
> not properly (or deterministically) enable optional blocks. That is why 
> we require everything be scoped locally to be used. We have, however, 
> made changes to the linker algorithm since the original module codebase 
> so it might have gotten better, but I don't think anyone has sat down 
> and figured out exactly which cases can be required and which ones may 
> be prevented.

The particular case is:
optional {
	require {
		type system_dbusd_t, system_dbusd_t, dbusd_etc_t;
		class dbus { send_msg acquire_svc };
		attribute dbusd_unconfined;
	}
	type swo_dbusd_t;
	...
}

require {
	type swo_t;
	type swo_dbusd_t;
	class dbus send_msg;
}
...

So the require that is triggering a misleading "duplicate
type/attribute" error under the current toolchain is not within an
optional block at all.  And if you switch the order, it compiles fine
(because we already allow decl-follows-require).  It shouldn't be order
dependent obviously.

In any event, the compiler breakage is preventing people from doing real
work, and doesn't seem to be a bug in policy.  It needs to be fixed.
		
-- 
Stephen Smalley
National Security Agency


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2008-10-22 at 13:42 -0400, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
>>>   
>>>       
>>>> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
>>>>     
>>>>         
>>>>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
>>>>>
>>>>>       
>>>>>           
>>>>>>   I did notice however that I could also get it to build w/o
>>>>>> changing checkmodule by reversing the order of the interface calls  
>>>>>> there
>>>>>> - not sure if that workaround is usable in the original case that
>>>>>> triggered this bug report.
>>>>>>         
>>>>>>             
>>>>> Arranging modules in the proper order becomes increasingly difficult  
>>>>> as module interaction grows. I finally de-optioned the X policy in  
>>>>> fedora since it is in base so get our additions to compile. Patch  
>>>>> included for reference.
>>>>>
>>>>> Making the compiler gracefully deal with options would really be  
>>>>> appreciated. I could see the issue in the compiler code, but the right  
>>>>> fix wasn't obvious.
>>>>>       
>>>>>           
>>>> Does the patch I posted fix your problem?
>>>>     
>>>>         
>>> And by fix, I mean not only does it allow you to build the policy but
>>> does it yield the expected final kernel policy (i.e. look at the
>>> policy.N file via apol and check that you are getting the expected types
>>> and rules in the final policy).
>>>   
>>>       
>> I just worry that allowing situations like this will cause the linker to 
>> not properly (or deterministically) enable optional blocks. That is why 
>> we require everything be scoped locally to be used. We have, however, 
>> made changes to the linker algorithm since the original module codebase 
>> so it might have gotten better, but I don't think anyone has sat down 
>> and figured out exactly which cases can be required and which ones may 
>> be prevented.
>>     
>
> The particular case is:
> optional {
> 	require {
> 		type system_dbusd_t, system_dbusd_t, dbusd_etc_t;
> 		class dbus { send_msg acquire_svc };
> 		attribute dbusd_unconfined;
> 	}
> 	type swo_dbusd_t;
> 	...
> }
>
> require {
> 	type swo_t;
> 	type swo_dbusd_t;
> 	class dbus send_msg;
> }
> ...
>
> So the require that is triggering a misleading "duplicate
> type/attribute" error under the current toolchain is not within an
> optional block at all.  And if you switch the order, it compiles fine
> (because we already allow decl-follows-require).  It shouldn't be order
> dependent obviously.
>
> In any event, the compiler breakage is preventing people from doing real
> work, and doesn't seem to be a bug in policy.  It needs to be fixed.
> 		
>   

Ok, waiting on Joe to respond with whether your last patch fixed his 
problems then I'll apply it here and see if it blows anything up.


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Stephen Smalley]

On Thu, 2008-10-23 at 10:10 -0400, Stephen Smalley wrote:
> On Wed, 2008-10-22 at 13:42 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
> > >   
> > >> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
> > >>     
> > >>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
> > >>>
> > >>>       
> > >>>>   I did notice however that I could also get it to build w/o
> > >>>> changing checkmodule by reversing the order of the interface calls  
> > >>>> there
> > >>>> - not sure if that workaround is usable in the original case that
> > >>>> triggered this bug report.
> > >>>>         
> > >>> Arranging modules in the proper order becomes increasingly difficult  
> > >>> as module interaction grows. I finally de-optioned the X policy in  
> > >>> fedora since it is in base so get our additions to compile. Patch  
> > >>> included for reference.
> > >>>
> > >>> Making the compiler gracefully deal with options would really be  
> > >>> appreciated. I could see the issue in the compiler code, but the right  
> > >>> fix wasn't obvious.
> > >>>       
> > >> Does the patch I posted fix your problem?
> > >>     
> > >
> > > And by fix, I mean not only does it allow you to build the policy but
> > > does it yield the expected final kernel policy (i.e. look at the
> > > policy.N file via apol and check that you are getting the expected types
> > > and rules in the final policy).
> > >   
> > 
> > I just worry that allowing situations like this will cause the linker to 
> > not properly (or deterministically) enable optional blocks. That is why 
> > we require everything be scoped locally to be used. We have, however, 
> > made changes to the linker algorithm since the original module codebase 
> > so it might have gotten better, but I don't think anyone has sat down 
> > and figured out exactly which cases can be required and which ones may 
> > be prevented.
> 
> The particular case is:
> optional {
> 	require {
> 		type system_dbusd_t, system_dbusd_t, dbusd_etc_t;
> 		class dbus { send_msg acquire_svc };
> 		attribute dbusd_unconfined;
> 	}
> 	type swo_dbusd_t;
> 	...
> }
> 
> require {
> 	type swo_t;
> 	type swo_dbusd_t;
> 	class dbus send_msg;
> }
> ...
> 
> So the require that is triggering a misleading "duplicate
> type/attribute" error under the current toolchain is not within an
> optional block at all.

I suppose it might be within an optional though in the original case,
just not in the trivial example produced by Joe to trigger the compiler
error.

>   And if you switch the order, it compiles fine
> (because we already allow decl-follows-require).  It shouldn't be order
> dependent obviously.
> 
> In any event, the compiler breakage is preventing people from doing real
> work, and doesn't seem to be a bug in policy.  It needs to be fixed.

...even if that means a rewrite of the require + optional handling
altogether.
	
-- 
Stephen Smalley
National Security Agency


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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Oct 22, 2008, at 9:32 AM, Stephen Smalley wrote:

> On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
>> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
>>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
>>>
>>>>  I did notice however that I could also get it to build w/o
>>>> changing checkmodule by reversing the order of the interface calls
>>>> there
>>>> - not sure if that workaround is usable in the original case that
>>>> triggered this bug report.
>>>
>>>
>>> Arranging modules in the proper order becomes increasingly difficult
>>> as module interaction grows. I finally de-optioned the X policy in
>>> fedora since it is in base so get our additions to compile. Patch
>>> included for reference.
>>>
>>> Making the compiler gracefully deal with options would really be
>>> appreciated. I could see the issue in the compiler code, but the  
>>> right
>>> fix wasn't obvious.
>>
>> Does the patch I posted fix your problem?
>
> And by fix, I mean not only does it allow you to build the policy but
> does it yield the expected final kernel policy (i.e. look at the
> policy.N file via apol and check that you are getting the expected  
> types
> and rules in the final policy).

I added your patch and Eamon's patch (not sure I needed Eamons's patch).
I can definitely build the policy now.
The types appear to be correct in apol and seinfo. It works as  
expected in enforcing.

joe

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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Joe Nall]

On Nov 23, 2008, at 9:35 PM, Joe Nall wrote:

>
> On Oct 22, 2008, at 9:32 AM, Stephen Smalley wrote:
>
>> On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
>>> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
>>>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
>>>>
>>>>> I did notice however that I could also get it to build w/o
>>>>> changing checkmodule by reversing the order of the interface calls
>>>>> there
>>>>> - not sure if that workaround is usable in the original case that
>>>>> triggered this bug report.
>>>>
>>>>
>>>> Arranging modules in the proper order becomes increasingly  
>>>> difficult
>>>> as module interaction grows. I finally de-optioned the X policy in
>>>> fedora since it is in base so get our additions to compile. Patch
>>>> included for reference.
>>>>
>>>> Making the compiler gracefully deal with options would really be
>>>> appreciated. I could see the issue in the compiler code, but the  
>>>> right
>>>> fix wasn't obvious.
>>>
>>> Does the patch I posted fix your problem?
>>
>> And by fix, I mean not only does it allow you to build the policy but
>> does it yield the expected final kernel policy (i.e. look at the
>> policy.N file via apol and check that you are getting the expected  
>> types
>> and rules in the final policy).
>
> I added your patch and Eamon's patch (not sure I needed Eamons's  
> patch).
> I can definitely build the policy now.
> The types appear to be correct in apol and seinfo. It works as  
> expected in enforcing.

It does need Eamon's patch. Any chance to test this on your end?

joe




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

Re: Use of optional_policy in templates (compiler bug or feature?)

[Stephen Smalley]

On Tue, 2008-12-02 at 08:26 -0600, Joe Nall wrote:
> On Nov 23, 2008, at 9:35 PM, Joe Nall wrote:
> 
> >
> > On Oct 22, 2008, at 9:32 AM, Stephen Smalley wrote:
> >
> >> On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
> >>> On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
> >>>> On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
> >>>>
> >>>>> I did notice however that I could also get it to build w/o
> >>>>> changing checkmodule by reversing the order of the interface calls
> >>>>> there
> >>>>> - not sure if that workaround is usable in the original case that
> >>>>> triggered this bug report.
> >>>>
> >>>>
> >>>> Arranging modules in the proper order becomes increasingly  
> >>>> difficult
> >>>> as module interaction grows. I finally de-optioned the X policy in
> >>>> fedora since it is in base so get our additions to compile. Patch
> >>>> included for reference.
> >>>>
> >>>> Making the compiler gracefully deal with options would really be
> >>>> appreciated. I could see the issue in the compiler code, but the  
> >>>> right
> >>>> fix wasn't obvious.
> >>>
> >>> Does the patch I posted fix your problem?
> >>
> >> And by fix, I mean not only does it allow you to build the policy but
> >> does it yield the expected final kernel policy (i.e. look at the
> >> policy.N file via apol and check that you are getting the expected  
> >> types
> >> and rules in the final policy).
> >
> > I added your patch and Eamon's patch (not sure I needed Eamons's  
> > patch).
> > I can definitely build the policy now.
> > The types appear to be correct in apol and seinfo. It works as  
> > expected in enforcing.
> 
> It does need Eamon's patch. Any chance to test this on your end?

I'm confused by that.  Eamon's patch shouldn't be necessary if my patch
was applied.

-- 
Stephen Smalley
National Security Agency


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