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
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
>
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
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
http://www.tresys.com | oss.tresys.com
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
>
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
>