[refpolicy] Build of 20120215 fails with unknown role system_r

[refpolicy] Build of 20120215 fails with unknown role system_r

[Sven Vermeulen]

While trying to build the 20120215 reference policy, I hit the following
problem while running "make base":

Compiling strict base module
/usr/bin/checkmodule:  loading policy configuration from base.conf
policy/modules/admin/bootloader.te":9:ERROR 'unknown role system_r' at token
';' on line 40265:
# this line was moved by the build process: attribute_role bootloader_roles;
roleattribute system_r bootloader_roles;
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/base.mod] Error 1

All utilities have been updated with the latest userspace release. Is the
system role defined somewhere that I forgot to include in my modules.conf? I
have the following modules marked for base:

application authlogin bootloader clock consoletype corecommands corenetwork
cron devices dmesg domain files filesystem fstools getty hostname hotplug
init iptables kernel libraries locallogin logging lvm miscfiles mcs mls
modutils mount mta netutils nscd portage raid rsync selinux selinuxutil ssh
staff storage su sysadm sysnetwork terminal ubac udev userdomain usermanage
unprivuser

Wkr,
	Sven Vermeulen

[refpolicy] Build of 20120215 fails with unknown role system_r

[Harry Ciao]

Hi Sven,

A quick answer is an identifier needs to be declared or required before 
it's ever referenced, otherwise it won't exist in the current module's 
p_roles hashtab, in consequence, the toolchain will bail out with 
"unknown role system_r" error.

The background story is that the role-types rule used to be able to 
declare a role, however, I have decided to remove this behavior and have 
the role-type rule only aimed for setting up the bondings between role 
and types. On the other hand, the newly added role-attribute rule will 
be used to declare a role, and optionally adding it to a role attribute. 
As a result, the role-attribute rule will be consistent with the 
type-attribute rule in terms of usage, and bares no ambiguity with the 
role-types rule.

system_r is actually defined in kernel.te. By default, there are only a 
limited number of modules that would be built into base.pp and its 
declaration happens before its first reference :

$ grep "= base" policy/modules.conf
corecommands = base
corenetwork = base
devices = base
domain = base
files = base
filesystem = base
kernel = base
mcs = base
mls = base
selinux = base
terminal = base
ubac = base

$ grep "role system_r" base.conf
role system_r;
role system_r types kernel_t;
$

However, in your case when many other loadable modules are built into 
base.pp, it's used before ever being defined or required:

$ cat -n base.conf > base.conf_num
$ grep "role system_r" base.conf_num | grep -v types
200351   role system_r;
397652            role system_r;
487887            role system_r;
$

Turns out the modules built into base.pp are sorted by their names.

A quick solution for this is to move system_r's declaration before its 
ever being used in the role-type rule, but the long term fix should be 
concerned with modification to get_type_attr_decl.sed and 
comment_move_decl.sed, to move role definitions along with 
attribute_role to the top of base.conf (Chris, could you jump in here?)

Thanks,
Harry



On 02/25/2012 06:05 PM, Sven Vermeulen wrote:
> While trying to build the 20120215 reference policy, I hit the following
> problem while running "make base":
>
> Compiling strict base module
> /usr/bin/checkmodule:  loading policy configuration from base.conf
> policy/modules/admin/bootloader.te":9:ERROR 'unknown role system_r' at token
> ';' on line 40265:
> # this line was moved by the build process: attribute_role bootloader_roles;
> roleattribute system_r bootloader_roles;
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> make: *** [tmp/base.mod] Error 1
>
> All utilities have been updated with the latest userspace release. Is the
> system role defined somewhere that I forgot to include in my modules.conf? I
> have the following modules marked for base:
>
> application authlogin bootloader clock consoletype corecommands corenetwork
> cron devices dmesg domain files filesystem fstools getty hostname hotplug
> init iptables kernel libraries locallogin logging lvm miscfiles mcs mls
> modutils mount mta netutils nscd portage raid rsync selinux selinuxutil ssh
> staff storage su sysadm sysnetwork terminal ubac udev userdomain usermanage
> unprivuser
>
> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>

[refpolicy] Build of 20120215 fails with unknown role system_r

[Sven Vermeulen]

On Sun, Feb 26, 2012 at 05:26:49PM +0800, Harry Ciao wrote:
[...]
> system_r is actually defined in kernel.te. By default, there are only a 
> limited number of modules that would be built into base.pp and its 
> declaration happens before its first reference :
> 
> $ grep "= base" policy/modules.conf
> corecommands = base
> corenetwork = base
> devices = base
> domain = base
> files = base
> filesystem = base
> kernel = base
> mcs = base
> mls = base
> selinux = base
> terminal = base
> ubac = base

Well, I'm currently looking at using the default set for our base policy
(which seems to work well) but is the base set something we need to fix (as
in, users of refpolicy shouldn't update the list of modules belonging to
base) or is it something configurable?

Wkr,
	Sven Vermeulen

[refpolicy] Build of 20120215 fails with unknown role system_r

[Christopher J. PeBenito]

On 02/26/12 07:24, Sven Vermeulen wrote:
> On Sun, Feb 26, 2012 at 05:26:49PM +0800, Harry Ciao wrote:
> [...]
>> system_r is actually defined in kernel.te. By default, there are only a 
>> limited number of modules that would be built into base.pp and its 
>> declaration happens before its first reference :
>>
>> $ grep "= base" policy/modules.conf
>> corecommands = base
>> corenetwork = base
>> devices = base
>> domain = base
>> files = base
>> filesystem = base
>> kernel = base
>> mcs = base
>> mls = base
>> selinux = base
>> terminal = base
>> ubac = base
> 
> Well, I'm currently looking at using the default set for our base policy
> (which seems to work well) but is the base set something we need to fix (as
> in, users of refpolicy shouldn't update the list of modules belonging to
> base) or is it something configurable?

Contents of the base module is supposed to be configurable, as long as you have all of the modules that are required to be in the base module, and all dependencies of the modules in base are met.

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

[refpolicy] Build of 20120215 fails with unknown role system_r

[Harry Ciao]

On 02/26/2012 05:26 PM, Harry Ciao wrote:
> Hi Sven,
>
> A quick answer is an identifier needs to be declared or required before
> it's ever referenced, otherwise it won't exist in the current module's
> p_roles hashtab, in consequence, the toolchain will bail out with
> "unknown role system_r" error.
>
> The background story is that the role-types rule used to be able to
> declare a role, however, I have decided to remove this behavior and have
> the role-type rule only aimed for setting up the bondings between role
> and types. On the other hand, the newly added role-attribute rule will
> be used to declare a role, and optionally adding it to a role attribute.
> As a result, the role-attribute rule will be consistent with the
> type-attribute rule in terms of usage, and bares no ambiguity with the
> role-types rule.
>
> system_r is actually defined in kernel.te. By default, there are only a
> limited number of modules that would be built into base.pp and its
> declaration happens before its first reference :
>
> $ grep "= base" policy/modules.conf
> corecommands = base
> corenetwork = base
> devices = base
> domain = base
> files = base
> filesystem = base
> kernel = base
> mcs = base
> mls = base
> selinux = base
> terminal = base
> ubac = base
>
> $ grep "role system_r" base.conf
> role system_r;
> role system_r types kernel_t;
> $
>
> However, in your case when many other loadable modules are built into
> base.pp, it's used before ever being defined or required:
>
> $ cat -n base.conf>  base.conf_num
> $ grep "role system_r" base.conf_num | grep -v types
> 200351   role system_r;
> 397652            role system_r;
> 487887            role system_r;
> $
>
> Turns out the modules built into base.pp are sorted by their names.
>
> A quick solution for this is to move system_r's declaration before its
> ever being used in the role-type rule, but the long term fix should be
> concerned with modification to get_type_attr_decl.sed and
> comment_move_decl.sed, to move role definitions along with
> attribute_role to the top of base.conf (Chris, could you jump in here?)

I just posted a half-baked patch to copy role declarations to the top of 
base.conf or policy.conf that could properly address your problem here. 
I would seek to comment off the original role declaration later.

Thanks,
Harry


> Thanks,
> Harry
>
>
>
> On 02/25/2012 06:05 PM, Sven Vermeulen wrote:
>> While trying to build the 20120215 reference policy, I hit the following
>> problem while running "make base":
>>
>> Compiling strict base module
>> /usr/bin/checkmodule:  loading policy configuration from base.conf
>> policy/modules/admin/bootloader.te":9:ERROR 'unknown role system_r' at token
>> ';' on line 40265:
>> # this line was moved by the build process: attribute_role bootloader_roles;
>> roleattribute system_r bootloader_roles;
>> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>> make: *** [tmp/base.mod] Error 1
>>
>> All utilities have been updated with the latest userspace release. Is the
>> system role defined somewhere that I forgot to include in my modules.conf? I
>> have the following modules marked for base:
>>
>> application authlogin bootloader clock consoletype corecommands corenetwork
>> cron devices dmesg domain files filesystem fstools getty hostname hotplug
>> init iptables kernel libraries locallogin logging lvm miscfiles mcs mls
>> modutils mount mta netutils nscd portage raid rsync selinux selinuxutil ssh
>> staff storage su sysadm sysnetwork terminal ubac udev userdomain usermanage
>> unprivuser
>>
>> Wkr,
>> 	Sven Vermeulen
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>

[refpolicy] Build of 20120215 fails with unknown role system_r

[Harry Ciao]

Hi Sven,

On 02/25/2012 06:05 PM, Sven Vermeulen wrote:
> While trying to build the 20120215 reference policy, I hit the following
> problem while running "make base":
>
> Compiling strict base module
> /usr/bin/checkmodule:  loading policy configuration from base.conf
> policy/modules/admin/bootloader.te":9:ERROR 'unknown role system_r' at token
> ';' on line 40265:
> # this line was moved by the build process: attribute_role bootloader_roles;
> roleattribute system_r bootloader_roles;
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> make: *** [tmp/base.mod] Error 1

This problem could be reproduced simply by adding the bootloader module 
into base.pp.

The root cause is that the policy_module() used to require system_r will 
be expanded as EMPTY if the module is built into base.pp (with 
"self_contained_policy" flag set), rendering modules(such as 
bootloader.te) that are copied earlier than kernel.te into base.conf 
found system_r not ever defined or required when referencing it in their 
unconditional block.

The solution is to bump role declarations in the unconditional block of 
base.pp to the top of base.conf, as what has been done for attribute, 
type, alias or boolean declarations. The patch just got posted to the 
mailing list.

Last, it's worthwhile to mention that the bootloader module could be 
properly built as a standalone module without such error, owing to the 
fact that policy_module() could require system_r properly.

Thanks,
Harry



> All utilities have been updated with the latest userspace release. Is the
> system role defined somewhere that I forgot to include in my modules.conf? I
> have the following modules marked for base:
>
> application authlogin bootloader clock consoletype corecommands corenetwork
> cron devices dmesg domain files filesystem fstools getty hostname hotplug
> init iptables kernel libraries locallogin logging lvm miscfiles mcs mls
> modutils mount mta netutils nscd portage raid rsync selinux selinuxutil ssh
> staff storage su sysadm sysnetwork terminal ubac udev userdomain usermanage
> unprivuser
>
> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>