This is the update I have made based on suggestions for the previous
patches to add a udev_run interface. This adds the new domain udevadm_t
which is entered from /usr/bin/udevadm.
It seems to meet the needs that I have, but there are some things to
note that are probably important.
1) There are a few systemd services that use udevadm during startup.
I have granted the permisssions that I need based on denials I was
seeing during startup (the machine would fail to start without the
permisions).
2) In the udev.fc file there are other binaries that I don't have on a
RHEL7 box that maybe should also be labeled udevadm_exec_t.
e.g. /usr/bin/udevinfo and /usr/bin/udevsend
But as I don't have those binaries to test, I have not updated the
type of that binary.
3) There are some places that call udev_domtrans that maybe should now
be using udevadm_domtrans - rpm.te, hal.te, hotplug.te. Again,
these are not things that I am using in my current situation and am
unable to test the interactions to know if the change is correct.
Other than that, I think this was a good suggestion to split udevadm
into a different domain.
Only change for v4 is to use stream_connect_pattern as suggested.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
I'm seeing a denial for udev to map /etc/udev/hwdb.bin.
This creates and uses a new interface to allow the needed
permission for udev.
type=AVC msg=audit(1551886176.948:642): avc: denied { map } for pid=5187 comm="systemd-udevd" path="/etc/udev/hwdb.bin" dev="dm-1" ino=6509618 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_hwdb_t:s0 tclass=file permissive=1
Updated from previous to create a new interface.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
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>
AIDE has a compile time option WITH_MMAP which allows AIDE to
map files during scanning. RHEL7 has set this option in the
aide rpm they distribute.
Changes made to add a tunable to enable permissions allowing
aide to map files that it needs. I have set the default to
false as this seems perfered (in my mind).
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Currently freshclam can only be started from cron or init. This adds
the option of starting from a different process and optionally
transitioning or staying in the callers domain.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
When trying to remove files_read_non_auth_files(restorecond_t), the
following AVC denial occurs:
type=AVC msg=audit(1550921968.443:654): avc: denied { open } for
pid=281 comm="restorecond"
path="/etc/selinux/refpolicy/contexts/customizable_types" dev="vda1"
ino=928006 scontext=system_u:system_r:restorecond_t
tcontext=system_u:object_r:default_context_t tclass=file
permissive=1
type=AVC msg=audit(1550921968.443:654): avc: denied { read } for
pid=281 comm="restorecond" name="customizable_types" dev="vda1"
ino=928006 scontext=system_u:system_r:restorecond_t
tcontext=system_u:object_r:default_context_t tclass=file
permissive=1
As /etc/selinux/${SELINUXTYPE}/contexts/customizable_types is needed by
restorecond, allow this access.
Since systemd 241, systemd-journald is using kill(pid, 0) in order to
find dead processes and reduce its cache. The relevant commit is
91714a7f42
("journald: periodically drop cache for all dead PIDs"). This commit
added a call to pid_is_unwaited(c->pid), which is a function implemented in
https://github.com/systemd/systemd/blob/v241/src/basic/process-util.c#L936 :
bool pid_is_unwaited(pid_t pid) {
/* Checks whether a PID is still valid at all, including a zombie */
if (pid < 0)
return false;
if (pid <= 1) /* If we or PID 1 would be dead and have been waited for, this code would not be running */
return true;
if (pid == getpid_cached())
return true;
if (kill(pid, 0) >= 0)
return true;
return errno != ESRCH;
}
This new code triggers the following AVC denials:
type=AVC msg=audit(1550911933.606:332): avc: denied { signull }
for pid=224 comm="systemd-journal"
scontext=system_u:system_r:syslogd_t
tcontext=system_u:system_r:auditd_t tclass=process permissive=1
type=AVC msg=audit(1550911933.606:333): avc: denied { signull }
for pid=224 comm="systemd-journal"
scontext=system_u:system_r:syslogd_t
tcontext=system_u:system_r:dhcpc_t tclass=process permissive=1
type=AVC msg=audit(1550911933.606:334): avc: denied { signull }
for pid=224 comm="systemd-journal"
scontext=system_u:system_r:syslogd_t
tcontext=system_u:system_r:sshd_t tclass=process permissive=1
I'm seeing a bunch of denials for various processes (some refpolicy
domains, some my own application domains) attempting to access
/etc/pki. They seem to be working OK even with the denial. The
tunable authlogin_nsswitch_use_ldap controls access to cert_t
(for domains that are part of nsswitch_domain attribute). Use this
new interface when that tunable is off to quiet the denials.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
When calling hostnamectl to set the hostname it needs sys_admin
capability to actually set the hostname.
Feb 13 11:47:14 localhost.localdomain systemd-hostnamed[7221]: Failed to set host name: Operation not permitted
type=AVC msg=audit(1550058524.656:1988): avc: denied { sys_admin } for pid=7873 comm="systemd-hostnam" capability=21 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:system_r:systemd_hostnamed_t:s0 tclass=capability permissive=0
Signed-off-by: Dave Sugar <dsugar@tresys.com>
init (systemd) needs to read /etc/hostname during boot
to retreive the hostname to apply to the system.
Feb 06 18:37:06 localhost.localdomain kernel: type=1400 audit(1549478223.842:3): avc: denied { read } for pid=1 comm="systemd" name="hostname" dev="dm-1" ino=1262975 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file 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
systemd-modules-load is used to pre-load kernal modules as the system comes up.
It was running initc_t which didn't have permissions to actually load kernel
modules. This change sets up a new domain for this service and grants permission
necessary to load kernel modules.
Feb 05 03:38:20 4c4c4544-0052-5410-8043-b1c04f503232 kernel: type=1400 audit(1549337898.886:10): avc: denied { read } for pid=4257 comm="systemd-modules" name="fuse.ko.xz" dev="dm-1" ino=2390271 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:modules_object_t:s0 tclass=file permissive=1
Feb 05 03:38:20 4c4c4544-0052-5410-8043-b1c04f503232 kernel: type=1400 audit(1549337898.886:11): avc: denied { open } for pid=4257 comm="systemd-modules" path="/usr/lib/modules/3.10.0-957.1.3.el7.x86_64/kernel/fs/fuse/fuse.ko.xz" dev="dm-1" ino=2390271 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:modules_object_t:s0 tclass=file permissive=1
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Chris PeBenito
Chris PeBenito
Sugar, David
Nicolas Iooss