Move code to convert a policy module to CIL from the policy package to
CIL conversion tool, pp, in policycoreutils to libsepol. The only changes
to the code are the additions of the prefix "sepol_" to the functions
sepol_module_package_to_cil() and sepol_ppfile_to_module_package(). This
code is being changed from GPL to LGPL with permission from Tresys.
Convert pp to use the renamed functions in libsepol.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
This expands IOMEMCON device context entries to 64 bits. This change is
required to support static I/O memory range labeling for systems with
over 16TB of physical address space. The policy version number change
is shared with the next patch.
While this makes no changes to SELinux policy, a new SELinux policy
compatibility entry was added in order to avoid breaking compilation of
an SELinux policy without explicitly specifying the policy version.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Currently, roletype statements are only added for types when they are
declared (not required). This means that in policy like:
require {
type foo_t;
}
type bar_t;
role staff_r types foo_t, bar_t;
only bar_t is associated with staff_r. This patch moves the code that
generates roletype statements for types to outside the SCOPE_DECL check
so that roletype statements are generated for all types, regardless of
the required/declared scope. It further moves the code outside of the
type/typeattribute flavor check so that roletype statements are also
generated for typeattributes.
Reported-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Reviewed-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Tested-by: Jason Zaman <jason@perfinion.com>
Previously, type aliases were converted to CIL in the global namespace,
regardless of which scope they were actually defined in. So essentially
type aliases could never be in optionals. For the most part this worked,
however, in some small number of cases, a type alias could reference a
type defined inside an optional. If that optional was disabled, the type
would be disabled and so the type alias would fail to resolve, causing
policy to fail to build.
Unfortunately, type alises are stored in pp modules different than other
symbols (e.g. types/roles/etc) so they must be added to scopes
differently. So this patch gathers up all type aliases in a list and
keeps track of which scope each type alias is defined in. When we enter
a new scope, use that list to determine which type alias are defined
there and print the appropriate CIL statements.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Reviewed-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
CIL does not have any concept of require blocks. Instead, CIL relies on
whether or not all statements inside an optional block resolve to
determine if an optional block should be enabled/disabled. However, a
small number of optional statements require a type that is not actually
used in the optional block. In old style policy, this would cause the
optional block to be disabled. However, in CIL, because the type is never
used, the optional block will remain enabled.
To maintain compatibility, we modify pp2cil to create a new attribute,
cil_gen_require, and all types/roles/attributes that are required in a
pp module/optional block are associated with this attribute. Thus, if a
type is required but not used, it will still fail to resolve in the
typeattributeset statement, causing the optional to correctly be
disabled.
Note that when compiling the CIL this generated from compiling refpolicy
pp modules with pp2cil, the extra CIL statements cause ~12.6MB increase
in maximum memory usage (129.7 MB to 142.3 MB). Though, compilation time
decreases by ~35% (26 seconds to 17 seconds).
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Reviewed-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Reported-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Some roles (i.e. user_r, staff_r, sysadm_r, system_r, unconfined_r) are
declared in the base module, and sometimes in non-base modules. This
could result in duplicate declarations of roles, which isn't allowed in
CIL. So for these roles, only generate their declarations if they appear
in a base module, otherwise ignore their declarations. All other roles
are printed regardlss of their declaration location.
Note that this means that if a policy author does not include one of the
roles in the base module then they will not be included in the resulting
policy, likely causing a compliation error in CIL.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Avrules that have the negation, star, or complement flag set for types
need typeattributes and typeattributesets that are generated. This caused
issues when these generated statements were inserted into conditionals, since
typeattributes/sets are not allowed in conditionals.
This change always prints typeattributes and typeattributesets
immediately unless the types appear inside of an avrule in conditionals or blocks.
For this special case, we print the typeattributes after the end
of each conditional/block.
Signed-off-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Acked-by: Steve Lawrence <slawrence@tresys.com>
Some module fc files do not contain a trailing new line. This
caused contexts to have their last character to be deleted. When
parsing each line from a fc file, we only strip off the last character
if it is a new line.
Signed-off-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Acked-by: Steve Lawrence <slawrence@tresys.com>
- Create role declarations no matter if the declaration is in base or
a module. Since CIL does not permit role re-declarations, this change
will break existing policies that have the same role declared in multiple
modules. To fix this, the policies will need to change the role to be
defined in a single place.
- Pass around the avrule_decl stack rather than just the most recent
decl. The full stack is needed to determine if identifiers are in
scope
- Only create roletype statements for a role and a type in two cases:
1) The role is declared/required and the type is declared/required in
the same scope or an ancestor scope of the role
2) The type is declared/required and the role is declared/required in
an ancestor scope of the type
Signed-off-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Acked-by: Steve Lawrence <slawrence@tresys.com>
log_err, cil_printf and cil_println use printf formats to process their
arguments. Use __attribute__((format(printf,...))) to make "gcc
-Wformat -Wformat-security" detect issues.
This detected this issue several times on a x86_64 system:
format '%lx' expects argument of type 'long unsigned int', but
argument has type 'uint32_t'
Fix this by introducing an explicit cast to unsigned long.
While at it, constify the format string argument of each function.
Acked-by: Steve Lawrence <slawrence@tresys.com>
"gcc -O2 -Wall -Werror" failed with two errors when building pp due to
the use of unitialized variables.
Acked-by: Steve Lawrence <slawrence@tresys.com>
Reads in a policy package file via stdin or via filename, and writes out
the equivilent CIL to stdout or to an output file, depending on the
parameters passed in.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
