fc_sort is the only/last build tool that requires a C compiler
Re-implement it in python, so that gcc dependencies can be dropped
The output of the C and the python version differ slightly in the order of equally specific file contexts
old:
/.* system_u:object_r:default_t
/sys(/.*)? system_u:object_r:sysfs_t
/mnt(/[^/]*) -l system_u:object_r:mnt_t
/mnt(/[^/]*)? -d system_u:object_r:mnt_t
/opt/.* system_u:object_r:usr_t
/var/.* system_u:object_r:var_t
/usr/.* system_u:object_r:usr_t
/srv/.* system_u:object_r:var_t
/tmp/.* <<none>>
/run/.* <<none>>
/dev/.* system_u:object_r:device_t
/etc/.* system_u:object_r:etc_t
new:
/.* system_u:object_r:default_t
/sys(/.*)? system_u:object_r:sysfs_t
/mnt(/[^/]*) -l system_u:object_r:mnt_t
/mnt(/[^/]*)? -d system_u:object_r:mnt_t
/dev/.* system_u:object_r:device_t
/etc/.* system_u:object_r:etc_t
/opt/.* system_u:object_r:usr_t
/run/.* <<none>>
/srv/.* system_u:object_r:var_t
/tmp/.* <<none>>
/usr/.* system_u:object_r:usr_t
/var/.* system_u:object_r:var_t
Every Infiniband network will have a default pkey, so that is labeled.
The rest of the pkey configuration is network specific. The policy allows
access to the default and unlabeled pkeys for sysadm and staff users.
kernel_t is allowed access to all pkeys, which it needs to process and
route management datagrams.
Endports are all unlabeled by default, sysadm users are allowed to
manage the subnet on unlabeled endports. kernel_t is allowed to manage
the subnet on all ibendports, which is required for configuring the HCA.
This patch requires selinux series: "SELinux user space support for
Infiniband RDMA", due to the new ipkeycon labeling mechanism.
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
When I synchronized my personal policy with the git master branch, "git
rebase" merged the file contexts I have defined for some systemd
components with the ones which have recently been merged. This resulted
in duplicated file contexts in systemd.fc, which made the policy unable
to be loaded.
This issue has not been detected by "make validate" because this command
only verifies policy linking, not the correctness of the file contexts.
Moreover this behavior of "make validate" only happens when building a
modular policy. Indeed Rules.monolithic calls setfiles in order to
validate the file contexts:
validate: $(fc) $(polver)
@echo "Validating $(NAME) file_contexts."
$(verbose) $(SETFILES) -q -c $(polver) $(fc)
@echo "Success."
Invoke setfiles in Rules.modular too in order to catch issues in file
contexts with "make validate". With the issue I experienced, I would
have got the following message:
Validating policy file contexts.
/sbin/setfiles -q -c tmp/policy.bin tmp/all_mods.fc
tmp/all_mods.fc: Multiple same specifications for /run/systemd/machines(/.*)?.
tmp/all_mods.fc: Invalid argument
make: *** [Rules.modular:210: validate] Error 1
While at it, simplify .SECONDARY definition with a newly-introduced
$(all_mod_fc) variable.
Before this commit, "make -j2" would execute twice at the same time the rules
written to build tmp/all_post.conf because these rules were applied every time
tmp/all_post.conf, tmp/all_attrs_types.conf and tmp/only_te_rules.conf needed
to be built. However, executing twice in parallel such line is buggy:
$(GREP) '^fs_use_(xattr|task|trans)' $(tmpdir)/all_te_files.conf >> \
tmpdir)/all_post.conf
This is why "make" reports following error for parallel builds:
Compiling refpolicy-patched base module
/usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod
/usr/bin/checkmodule: loading policy configuration from base.conf
policy/modules/kernel/ubac.te":710:ERROR 'syntax error' at token
'fs_use_trans' on line 26520:
fs_use_trans devtmpfs system_u:object_r:device_t:s0;
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [tmp/base.mod] Error 1
This commit fixes this bug by splitting the rules in 3 different targets, in
both monolithic and modular builds.
Christian Göttsche
Chris PeBenito
Daniel Jurgens
Nicolas Iooss
Guido Trentalancia
Chris PeBenito