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>
There are several nacl binaries that need labels.
Put an ifdef debian for some chromium paths.
Git policy misses chromium_role() lines, were they in another patch that was
submitted at the same time?
I don't know what this is for but doesn't seem harmful to allow it:
type=PROCTITLE msg=audit(28/01/19 19:31:42.361:3218) : proctitle=/bin/bash /usr/bin/google-chrome
type=SYSCALL msg=audit(28/01/19 19:31:42.361:3218) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x563328f7b590 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=0 ppid=5158 pid=5166 auid=test uid=test gid=test euid=test suid=test fsuid=test egid=test sgid=test fsgid=test tty=pts7 ses=232 comm=google-chrome exe=/bin/bash subj=user_u:user_r:chromium_t:s0 key=(null)
type=AVC msg=audit(28/01/19 19:31:42.361:3218) : avc: granted { associate } for pid=5166 comm=google-chrome name=63 scontext=user_u:object_r:chromium_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem
type=AVC msg=audit(28/01/19 19:31:42.361:3218) : avc: granted { create } for pid=5166 comm=google-chrome name=63 scontext=user_u:user_r:chromium_t:s0 tcontext=user_u:object_r:chromium_t:s0 tclass=file
type=AVC msg=audit(28/01/19 19:31:42.361:3218) : avc: granted { add_name } for pid=5166 comm=google-chrome name=63 scontext=user_u:user_r:chromium_t:s0 tcontext=user_u:user_r:chromium_t:s0 tclass=dir
Allow domain_use_interactive_fds() for running via ssh -X.
Allow managing xdg data, cache, and config.
Allow reading public data from apt and dpkg, probably from lsb_release or some
other shell script.
How does the whold naclhelper thing work anyway? I'm nervous about process
share access involving chromium_sandbox_t, is that really what we want?
Added lots of other stuff like searching cgroup dirs etc.
Sugar, David
Chris PeBenito
Nicolas Iooss
Russell Coker
Alexander Miroshnichenko