I have come up a fix for this issue, also there are some comments I
would like to share with you, see my comments below.
On 02/23/2012 06:22 PM, Harry Ciao wrote:
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)
When building a loadable module, no link and expansion would be
involved, and the symbol table and rules of an optional block (to be
precisely, the enabled decl of the block) will be written to its .pp file.
However, things are different for the base module, the compiling of
which requires link and expansion.
During expansion, all out-of-scope symbol will be skipped over, so are
the rules for an optional block if any of its required symbols is
out-of-scope. Which means such optional block will NOT be written into
base.pp at all.
$ 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.
The fix for this problem is easy. Since role_copy_callback will skip
out-of-scope roles, role_fix_callback should skip them too. The simple
patch has been posted to the mailing list.
Moreover, as I mentioned beforehand the optional block with required
symbols not properly declared will be omitted during expansion, the base
module generated by the above example x.te file won't work as expected.
Thanks for prompting me to think this through.
Cheers,
Harry
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@xxxxxxxxxxxxxx
To: selinux@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
