Without this fix, building a custom module in a directory that contains
a file with special characters in its name (e.g. '(') triggers a syntax
error:
$ cat >foo.te <<EOF
module foo 1.0;
require {
class file entrypoint;
type shell_exec_t;
type vmtools_unconfined_t;
}
allow vmtools_unconfined_t shell_exec_t : file entrypoint;
EOF
$ touch "my broken (file)"
$ make -f /usr/share/selinux/devel/Makefile foo.pp
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `find anaconda-ks.cfg my broken (file) vncserver.strace systemd.strace rhel-server-7.6-x86_64-boot.iso rt_minimal.c vnc.cil foo.te rsyslog tmp virt-install.log evil_banner.sh livemedia.log program.log foo.if rhel7-minimal.ks TestZip.java TestZip.class foo.fc sudoloop foo.pp strace.log -maxdepth 0 -type d'
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1692676
Reported-by: Renaud Métrich <rmetrich@redhat.com>
Suggested-by: Petr Lautrbach <plautrba@redhat.com>
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Devices with the netcontrol_device_t type are actually PM QoS devices.
Rename the type and add labeling for /dev/memory_bandwidth.
Signed-off-by: Chris PeBenito <Christopher.PeBenito@microsoft.com>
An example is mmcblk0rpmb, which is for the replay protected memory block
subsystem.
Signed-off-by: Chris PeBenito <Christopher.PeBenito@microsoft.com>
plymouth is started very early in the boot process. Looks
like before the SELinux policy is loaded so plymouthd is
running as kernel_t rather than plymouthd_t. Due to this
I needed to allow a few permissions on kernel_t to get
the system to boot.
type=AVC msg=audit(1554917011.127:225): avc: denied { write } for pid=2585 comm="plymouthd" name="plymouth" dev="tmpfs" ino=18877 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_run_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1554917011.127:226): avc: denied { remove_name } for pid=2585 comm="plymouthd" name="pid" dev="tmpfs" ino=18883 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_run_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1554917011.127:227): avc: denied { unlink } for pid=2585 comm="plymouthd" name="pid" dev="tmpfs" ino=18883 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1554917011.116:224): avc: denied { write } for pid=2585 comm="plymouthd" name="boot-duration" dev="dm-16" ino=2097285 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_lib_t:s0 tclass=file permissive=1
type=AVC msg=audit(1555069712.938:237): avc: denied { ioctl } for pid=2554 comm="plymouthd" path="/dev/dri/card0" dev="devtmpfs" ino=12229 ioctlcmd=64b1 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0
This patch is based on comments from previous a patch to
remove the many uses of kernel_dgram_send() and incorporate
it into logging_send_syslog_msg().
v2 - enclose in ifdef for redhat
v3 - rebase this patch on e41def136a
Signed-off-by: Dave Sugar <dsugar@tresys.com>
CRIU can influence the PID of the threads it wants to create.
CRIU uses /proc/sys/kernel/ns_last_pidto tell the kernel which
PID it wants for the next clone().
So it has to write to that file. This feels like a problematic as
it opens up the container writing to all sysctl_kernel_t.
Using new label container_t will just write to
sysctl_kernel_ns_last_pid_t instad writing to more generic
sysctl_kernel_t files.