Deprecate mmap_file_perms and mmap_files_pattern since they are not fully
informative about their access. Replace with a full set of permission
set macros for mmap.
Requested for selinux-testsuite usage.
NVMe has several dev nodes for each device:
/dev/nvme0 is a char device for communicating with the controller
/dev/nvme0n1 is the block device that stores the data.
/dev/nvme0n1p1 is the first partition
Setup attribute user_runtime_content_type in userdomain for files in /run/user/%{USERID}/* interfaces to associate this attribute with types and interfaces to delete types with this attribute.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
This patch properly completes the implementation of the MLS file relabel attributes. In the previous patch [http://oss.tresys.com/pipermail/refpolicy/2016-July/008038.html], a new attribute, mlsfilerelabetoclr, was created. There should have been a second attribute, mlsfilerelabel, created instead of overloading mlsfilewrite for this privilege. I concur with creating new attributes for this situation. I have created the patch below.
Signed-off-by: Chad Hanson <dahchanson@gmail.com>
I am seeing (on RHEL 7.4 w/systemd) that halting the system doesn't work. It took me a long time (and a lot of help from Steve L.) to figure out what was going on. It turns out in refpolicy the default label for /usr/lib/systemd/systemd-shutdown is bin_t. But when systemd tried to execve systemd-shutdown it fails because init_t isn't allowed file entrypoint for bin_t. When I labeled systemd-shutdown as init_exec_t shutting down the system works.
I was seeing the following log (from systemd) when I enabled systemd debug logging (which was very useful).
[ 59.745037] systemd[1]: Starting Final Step.
[ 59.746112] systemd[1]: Starting Power-Off...
[ 59.776320] systemd[1]: Shutting down.
[ 59.783559] systemd[1]: Failed to execute shutdown binary, freezing: Operation not permitted
At this point everything locks up instead of actually halting the system.
This is a patch to change the label for systemd-shutdown which solves the problem. I'm happy to go through and make a distinct type of systemd-shutdown if someone doesn't think it is a good idea to share the type with systemd. But based on what is going on, this might be reasonable.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
This is probably RHEL only - seeing directories in /run/user/$(UID) created as
tmpfs_t rather than user_runtime_t. This appears fixed in newer systemd-logind.
It appears to have been fixed in systemd git repo by Nicolas Iooss 02-Feb-2016
hash 4b51966cf6c06250036e428608da92f8640beb96 probably in systemd-v229
I don't see this merged into RHEL 7.x as of now but as some point it hopefully
will be merged in and this can go away.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Currently .xsession-errors is labeled user_home_t when created by xdm_t. Switch to using existing interface xserver_user_home_dir_filetrans_user_xsession_log to create file with label xsession_log_t. This includes using the interface manage the type xsession_log_t.
type=AVC msg=audit(1511962175.985:77): avc: denied { create } for pid=1163 comm="lightdm" name=".xsession-errors" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xsession_log_t:s0 tclass=file
type=AVC msg=audit(1511962175.985:77): avc: denied { write open } for pid=1163 comm="lightdm" path="/home/user/.xsession-errors" dev="dm-0" ino=17153285 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xsession_log_t:s0 tclass=file
type=AVC msg=audit(1511962941.991:268): avc: denied { rename } for pid=1721 comm="lightdm" name=".xsession-errors" dev="dm-0" ino=17153285 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xsession_log_t:s0 tclass=file
type=AVC msg=audit(1511962977.779:419): avc: denied { unlink } for pid=1814 comm="lightdm" name=".xsession-errors.old" dev="dm-0" ino=17153285 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xsession_log_t:s0 tclass=file
Signed-off-by: Dave Sugar <dsugar@tresys.com>
RHEL 7.x includes the directory /var/lib/lightdm-data in the lightdm RPM. Label these files xdm_var_lib_t
Signed-off-by: Dave Sugar <dsugar@tresys.com>
The cgroup directory under /sys/fs/cgroup contains a number of
pseudo-filesystems for each cgroup as well as two symbolic links for the
cpu and cpuacct groups, which were legacy symbolic links to the
cpu,cpuacct group.
These rules allow systemd to relabel these symbolic links from tmpfs_t
to their proper context, or otherwise denials will be printed for nearly
all systemd operation involving cgroups.
This change only grants systemd the possibility to relabel the
files. The actual relabelling needs to be done by systemd. The
accompanying change (commit 8739f23) will be released with systemd v236.
The ttm module, a dependency of radeon/amdgpu, does some
capable(CAP_SYS_ADMIN) checks. Changes in 4.13 have caused some of these
checks to be executed during module initialization, in the context of
modprobe, which fills the audit logs with a lot of denials.
Since failing these capable() checks is not an issue (they merely
control the access to emergency memory reserves, which shouldn't be an
issue during boot), I'm dontauditing them.
One potential issue with this is that if a module that actually needs
CAP_SYS_ADMIN during initialization comes along later, the dontaudit is
going to make the debugging a bit more annoying. Is anyone concerned
about this?
Chris PeBenito
Miroslav Grepl
Christian Göttsche
Nicolas Iooss
Jason Zaman
David Sugar
Chad Hanson
David Sugar via refpolicy
Laurent Bigonville
Krzysztof Nowicki
Luis Ressel