On 10/02/2014 11:25 AM, Steve Lawrence wrote:
On 10/02/2014 11:08 AM, James Carter wrote:
On 10/02/2014 10:58 AM, Steve Lawrence wrote:
On 10/02/2014 10:44 AM, James Carter wrote:
On 10/02/2014 09:10 AM, Yuli Khodorkovskiy wrote:
This patchset provides fixes to the pp2cil tool based on feedback for
2014-08-26-rc1.
An issue was encountered in 2014-08-26-rc1 with missing roles [1].
Role declarations will now be printed in base and modules, where
before only module role declarations were printed. Also, roletype
statements will only be created when a role or a type are in the
correct scope. As a result of these changes, policies that declare
roles mulitple times in different modules will result in pp2cil
generating duplicate roles. Since CIL does not allow identical role
delcarations in different modules, current policies must be rebuilt
with a refpolicy patch that removes duplicate role declarations [2].
What about current policies? How does this effect backwards
compatibility?
Unfortunately, this solution is not very backwards compatible. In order
to update to the latest userspace, it would require distributions to
update to the latest refpolicy or to pull in the refpolicy patch
referenced below. However, we have already found issues in distribution
policies that caused breakage that require distributions to update their
policies (e.g. bad filecon statements in fedora), so this isn't a
particularly new. It does potentially affect all policies though, and
not just a single distros version of policy, so it's a bit bigger.
I wouldn't expect this would affect custom policy modules that aren't
part of refpolicy, since most of those either don't contain role
declarations, or if they do, I'd guess they are custom roles that
wouldn't be duplicated eleswhere. So if the distro updated their
policy, then custom user modules shouldn't have any problems. This is
just an assumption though. It may be wrong.
We could provide a backwards compatibility mode in CIL that allows
duplicate roles, and eventually work to phase it out. Though, I'd really
like to avoid that.
I really don't want that.
But we know which roles are declared in the base module. So can't we
just not write those role declarations if they occur in a module? It is
a horrible and ugly hack, but it should work.
So make it so that staff_r, user_r, sysadm_r, system_r, and unconfined_r
are hardcoded into pp2cil and always generated from base? And all other
roles are generated from modules? Hacky, but I think it would work, at
least for Fedora, Gentoo, and refpolicy, which appear to be consistent
with the roles that are in the base module.
Yes. That should work.
If you want, you could make an option that would disable that behavior.
A bug in creating filecon statements was also fixed where a missing
trailing newline in .fc files would cause parsing issues.
Finally, generated typeattribute/sets will now be printed immediately
unless they are in avrule conditionals/blocks. The special case will
have generated typeattributes/sets to be printed after the
conditionals/blocks are printed.
[1] http://marc.info/?l=selinux&m=140983712508791&w=2
[2]
https://github.com/TresysTechnology/refpolicy/commit/330b0fc3331d3b836691464734c96f3da3044490
Yuli Khodorkovskiy (3):
policycoreutils/hll/pp: Fix role/roletype scoping
policycoreutils/hll/pp: fix '\n' parsing in filecon statements
policycoreutils/hll/pp: change printing behavior of
typeattribute/sets
policycoreutils/hll/pp/pp.c | 763
++++++++++++++++++++++++++++++--------------
1 file changed, 529 insertions(+), 234 deletions(-)
--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
