Re: role_fix_callback assertion with sysadm in base - base VS loadable module

[Harry Ciao <qingtao.cao@windriver.com>]

Hi Martin,

On 02/23/2012 07:22 AM, Martin Orr wrote:
> Sorry, I failed to make it clear that the requires causing problems are
> in optional blocks.
>
> Perhaps might make it clearer if I remove the refpolicy machinery.
> Ignore everything below except the attribute_role stuff - the rest is
> just needed to get something which compiles.
>
> In each case, the base module optionally requires the role attribute
> foo.  This works if the attribute is defined in the base but not
> otherwise.  Both examples work if foo is a type instead of an
> attribute_role.

No comments about why if foo is a type attribute then its declaration 
could be optional (not momentarily required) in the base module. 
Hypothetically, base module should be self-contained so that other 
modules could add on top of it.

(Perhaps this is a toolchain bug, but I am not sure, need more time to 
understand why link_modules() failed to find this undeclared symbol)

>    $ cat x.te
> class file
> sid kernel
> class file {
>          read
> }
>
> optional {
>          require {
>                  attribute_role foo;
>          }
> }
>
> type kernel_t;
> user system_u roles { object_r };
> sid kernel system_u:object_r:kernel_t
>
>    $ checkmodule x.te
> checkmodule:  loading policy configuration from x.te
> checkmodule: expand.c:700: role_fix_callback: Assertion `new_role != ((void *)0)&&  new_role->flavor == 1' failed.
> Aborted

If you break above assertion into two parts, you will see that it aborts 
at the criteria of

new_role != ((void *)0)


The reason is that during expansion any undeclared role identifiers 
would be skipped (see role_copy_callback > is_id_enabled, which will 
return 0 if it fails to find a SCOPE_DECL type of scope_datum_t for the 
current identifier), resulting in the foo attribute won't even be 
properly copied from the base module to the out module.

At last the expand_module > role_fix_callback will find foo identifier 
does not exist in out.p_roles hashtab, that's exactly how above 
assertion is failed.

Last but not least, if you want to build a loadable module, the "-m" 
option would have to be used for checkmodule, otherwise it will try to 
build a base module by default and then tries to call link_modules() and 
expand_module(), which makes no sense for loadable modules.

Thanks,
Harry

>    $ cat y.te
> class file
> sid kernel
> class file {
>          read
> }
>
> attribute_role foo;
> optional {
>          require {
>                  attribute_role foo;
>          }
> }
>
> type kernel_t;
> user system_u roles { object_r };
> sid kernel system_u:object_r:kernel_t
>
>    $ checkmodule y.te
> checkmodule:  loading policy configuration from y.te
> checkmodule:  policy configuration loaded
>
> On Sat, Feb 18, 2012 at 03:02:23PM +0000, HarryCiao wrote:
>> So far I am not 100% sure, but I am extra sure that certain cautions
>> must be taken when requiring a module to be built into base.pp rather
>> than as loadable module. In particular, while building the base module
>> the "self_contained_policy" macro is defined, exactly the same as when
>> building a monolithic policy image, which will influence if the
>> gen_require() macro would be properly expanded to the "require"
>> keyword. Below is the definition of the gen_require() macro:
>>
>> define(`gen_require',`
>>          ifdef(`self_contained_policy',`
>>                  ifdef(`__in_optional_policy',`
>>                          require {
>>                                  $1
>>                          } # end require
>>                  ')
>>          ',`
>>                  require {
>>                          $1
>>                  } # end require
>>          ')
>> ')
>>
>> Where we can clearly see that if the "self_contained_policy" is
>> defined,  ONLY WHEN the "__in_optional_policy" is also defined, would
>> gen_require() be expaned to the require keyword. BTW,
>> "__in_optional_policy" is defined only within an optional_policy()
>> block.
>>
>> That's why I take it for granted that you would have to include the
>> actual definition of a role attribute along with the module that
>> requires it into the base module.
>>
>> Cheers,
>> Harry
>>
>>
>>> Date: Thu, 9 Feb 2012 22:58:47 +0000
>>> From: martin@martinorr.name
>>> To: selinux@tycho.nsa.gov
>>> Subject: role_fix_callback assertion with sysadm in base
>>>
>>> I tried to build latest git refpolicy (6da98efd) using latest
>>> checkpolicy and libsepol (339f8079) with the attached modules.conf.
>>> In particular this puts sysadm into base.pp, and minimal other things.
>>>    I get the following error.
>>>
>>> Compiling refpolicy base module
>>> /usr/bin/checkmodule base.conf -o tmp/base.mod
>>> /usr/bin/checkmodule:  loading policy configuration from base.conf
>>> checkmodule: expand.c:700: role_fix_callback: Assertion `new_role !=
>>> ((void *)0)&&  new_role->flavor == 1' failed.
>>> make: *** [tmp/base.mod] Aborted
>>>
>>> -- 
>>> Martin Orr
>>   		 	   		

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