In many cases, this won't result in a change in the actual policy generated, but if the definitions of macros are changed going forward, the mismatches could cause issues.
Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
Kernel commit 6941857e82ae ("selinux: add a map permission check
for mmap") added a map permission check on mmap so that we can
distinguish memory mapped access (since it has different implications
for revocation). The purpose of a separate map permission check on
mmap(2) is to permit policy to prohibit memory mapping of specific files
for which we need to ensure that every access is revalidated, particularly
useful for scenarios where we expect the file to be relabeled at runtime
in order to reflect state changes (e.g. cross-domain solution, assured
pipeline without data copying). The kernel commit is anticipated to
be included in Linux 4.13.
This refpolicy change defines map permission for refpolicy. It mirrors
the definition in the kernel classmap by adding it to the common
definitions for files and sockets. This will break compatibility for
kernels that predate the dynamic class/perm mapping support (< 2.6.33,
< RHEL 6); on such kernels, one would instead need to add map permission
to the end of each file and socket access vector.
This change only allows map permission as needed, e.g. only in the
mmap_file_perms and exec_file_perms object permission sets
(since map is always required there) and only in specific interfaces
or modules where denials were observed in limited testing.
It is important to note that effective use of this permission requires
complete removal of unconfined, as otherwise unconfined domains will be
able to map all file types and therefore bypass the intended protection.
If we wanted to exclude map permission to all file types by default from
unconfined, we would need to add it to the list of permissions excluded from
files_unconfined_type in kernel/files.te.
Policies that depend on this permission not being allowed to specific file
types should also make use of neverallow rules to ensure that this is not
undermined by any allow rule, and ensure that they are performing neverallow
checking at policy build time (e.g. make validate) or runtime (e.g.
semanage.conf expand-check=1).
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
commit a7334eb0de98af11ec38b6263536fa01bc2a606c
libsemanage: validate and compile file contexts before installing
validates the fcontexts when they are still in /var/lib/selinux. Without
setfiles_t having access to read the files, validation fails and the
policy cannot be updated.
With the new userspace, the only files in /var/lib/selinux are selinux
store related files, so label it and everything inside it as
semanage_store_t. semanage_var_lib_t is completely removed and now
aliases semanage_store_t for backwards compatibility. This differs from
the v2 patch in that it adds back the ability to manage
selinux_config_t, which is necessary to manage the old module store for
things like migrating from the old to new store and backwards
compatability.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
With new userspace, trying to build a SELinux policy (and load it)
fails:
~# semodule -B
libsemanage.semanage_install_active: Unable to create sybolic link from
/etc/selinux/mcs/modules/active/policy.kern to
/etc/selinux/mcs/policy/policy.28 error code 0. (Permission denied).
AVC shows a denial for the semodule command, running as semanage_t,
trying to create a lnk_file in semanage_module_t.
Daniel Burgener
Daniel Burgener
bauen1
Luis Ressel
Chris PeBenito
Stephen Smalley
Jason Zaman via refpolicy
Nicolas Iooss
Jason Zaman
Steve Lawrence
Laurent Bigonville
Sven Vermeulen
Chris PeBenito
Dominick Grift