In order to detect bugs like the one fixed by commit d938683bf4
("drbd: fix pattern for /usr/lib/ocf/resource.d/linbit/drbd"), forbid
the use of \d in the policy. This was actually only used to match
/usr/share/apr-1/build/...
with
/usr/share/apr(-\d)?/build/[^/]+\.sh -- gen_context(system_u:object_r:bin_t,s0)
/usr/share/apr(-\d)?/build/libtool -- gen_context(system_u:object_r:bin_t,s0)
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Debian's PAM configuration uses a patched pam_motd module that runs
files in /etc/update-motd.d/ in order to generate a dynamic Message Of
The Day (MOTD). By default, there is only one script:
$ cat /etc/update-motd.d/10-uname
#!/bin/sh
uname -snrvm
According to https://wiki.debian.org/motd, the script is executed
through run-parts:
if (!system("/usr/bin/env -i
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
run-parts --lsbsysinit /etc/update-motd.d >
/run/motd.dynamic.new"))
rename("/run/motd.dynamic.new", "/run/motd.dynamic");
This requires allowing pam_motd users to execute bin_t commands
(/usr/bin/env) and shells (/bin/sh), and to manage /run/motd.dynamic*
files.
Allow relevant accesses for Debian-based systems.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
The pattern "(.*)?" means "match anything including the nothing, or
nothing": the question mark is redundant. This is likely to be a
mispelling for "(/.*)?", which means "match a slash and anthing, or
nothing", or for ".*", or for other patterns.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In a pattern, a dot can match any character, including slash. It makes
sense when it is combined with ?, + or *, but makes little sense when
left alone.
Most of the time, the label was for file containing dots, where the dot
was not escaped. A few times, the dot was really intended to match any
character. In such case, [^/] better suits the intent.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
The pattern that matches /usr/include uses a dot, in order probably to
avoid calling m4's function include(). This also matches other paths
such as /usr/inclu/e. Such a side-effect can be avoided by inserting an
empty string which is removed by m4's preprocessing.
Mailing-list discussion: https://lore.kernel.org/selinux-refpolicy/CAJfZ7=krh_TaCBQzFxLM394Sc5-82ZO0DdcfvWON-RXu-wqBVw@mail.gmail.com/t/#u
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
type=AVC msg=audit(1560944462.698:217): avc: denied { map } for pid=1265 comm="rpm" path="/sys/fs/selinux/status" dev="selinuxfs" ino=19 scontext=system_u:system_r:rpm_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file permissive=1
v2 - Create new interface to allow mapping security_t and use this interface by rpm_t
Signed-off-by: Dave Sugar <dsugar@tresys.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
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.
I have a case where I'm labeling media with my own types to control
access. But that is requiring that I relabel from iso9660_t to my
own type. This interface allows that relabel.
type=AVC msg=audit(1551621984.372:919): avc: denied { relabelfrom } for pid=9717 comm="mount" scontext=staff_u:staff_r:mymedia_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iso9660_t:s0 tclass=filesystem permissive=0
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Stubby is a DNS resolver that encrypts DNS queries and transmits them to
a resolver in a TLS channel. It therefore requires less permissions than
a traditionnal DNS resolver such as named or unbound (provided by module
"bind").
cf. https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
This program is packaged for Arch Linux, Debian, etc.
DNS-over-TLS uses TCP port 853, which does not seem to conflict with
existing ports. Label it like other DNS ports.
init_dbus_chat(stubby_t) is required on systemd-based distributions
because stubby's service uses DynamicUser=yes [1]. Without this
statement, the following denials are reported by dbus:
type=USER_AVC msg=audit(1550007165.936:257): pid=274 uid=81
auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t
msg='avc: denied { send_msg } for msgtype=method_call
interface=org.freedesktop.DBus member=Hello
dest=org.freedesktop.DBus spid=649
scontext=system_u:system_r:stubby_t
tcontext=system_u:system_r:system_dbusd_t tclass=dbus permissive=1
exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1550007165.939:258): pid=274 uid=81
auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t
msg='avc: denied { send_msg } for msgtype=method_call
interface=org.freedesktop.systemd1.Manager
member=LookupDynamicUserByUID dest=org.freedesktop.systemd1 spid=649
tpid=1 scontext=system_u:system_r:stubby_t
tcontext=system_u:system_r:init_t tclass=dbus permissive=1
exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1550007165.939:259): pid=274 uid=81
auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t
msg='avc: denied { send_msg } for msgtype=method_return dest=:1.39
spid=1 tpid=649 scontext=system_u:system_r:init_t
tcontext=system_u:system_r:stubby_t tclass=dbus permissive=1
exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
[1] https://github.com/getdnsapi/stubby/blob/v0.2.5/systemd/stubby.service#L8
