On Arch Linux, /proc/sys/kernel/core_pattern contains:
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
When a crash happens in a userspace application, this setting makes the
kernel spawn /usr/lib/systemd/systemd-coredump from kernel_t:
type=AVC msg=audit(1569910108.877:336): avc: denied { execute }
for pid=1087 comm="kworker/u2:3" name="systemd-coredump" dev="vda1"
ino=406365 scontext=system_u:system_r:kernel_t
tcontext=system_u:object_r:systemd_coredump_exec_t tclass=file
permissive=1
Introduce a transition to systemd_coredump_t to handle this.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
"systemd --user" spawns programs from
/usr/lib/systemd/user-environment-generators/ in order to gather
environment variables. On a Debian 10 virtual machine which gnupg, this
directory contains:
$ ls -Z /usr/lib/systemd/user-environment-generators
system_u:object_r:bin_t 30-systemd-environment-d-generator
system_u:object_r:bin_t 90gpg-agent
For sysadm, these programs are run as sysadm_t (because there is a
transition in systemd_role_template() in systemd.if:
corecmd_bin_domtrans($1_systemd_t, $3)) but use file descriptors created
by their parent process, which runs as sysadm_systemd_t. This leads to:
type=AVC msg=audit(1569756917.537:244): avc: denied { use } for
pid=9713 comm="30-systemd-envi"
path=2F6D656D66643A33302D73797374656D642D656E7669726F6E6D656E742D642D67656E657261746F72202864656C6574656429
dev="tmpfs" ino=24859 scontext=sysadm_u:sysadm_r:sysadm_t
tcontext=sysadm_u:sysadm_r:sysadm_systemd_t tclass=fd permissive=0
type=AVC msg=audit(1569756917.537:244): avc: denied { use } for
pid=9713 comm="30-systemd-envi"
path="/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator"
dev="vda1" ino=655822 scontext=sysadm_u:sysadm_r:sysadm_t
tcontext=sysadm_u:sysadm_r:sysadm_systemd_t tclass=fd permissive=0
type=SYSCALL msg=audit(1569756917.537:244): arch=c000003e syscall=59
success=no exit=-13 a0=5647d12cf020 a1=7ffc605b1fb0 a2=7ffc605b2420
a3=0 items=0 ppid=9712 pid=9713 auid=1000 uid=1000 gid=1000
euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000
tty=(none) ses=10 comm="30-systemd-envi"
exe="/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator"
subj=sysadm_u:sysadm_r:sysadm_t key=(null)
[...]
type=AVC msg=audit(1569756917.541:246): avc: denied { use } for
pid=9714 comm="90gpg-agent"
path=2F6D656D66643A39306770672D6167656E74202864656C6574656429
dev="tmpfs" ino=24860 scontext=sysadm_u:sysadm_r:sysadm_t
tcontext=sysadm_u:sysadm_r:sysadm_systemd_t tclass=fd permissive=0
type=AVC msg=audit(1569756917.541:246): avc: denied { use } for
pid=9714 comm="90gpg-agent" path="/usr/bin/bash" dev="vda1"
ino=524662 scontext=sysadm_u:sysadm_r:sysadm_t
tcontext=sysadm_u:sysadm_r:sysadm_systemd_t tclass=fd permissive=0
In systemd's source, here are the relevant functions:
* manager_run_environment_generators() calls execute_directories(paths,
DEFAULT_TIMEOUT_USEC, gather_environment, ...) [1], with
gather_environment a global table defined in exec-util.c [2]
* execute_directories() opens a "serialization fd" [3], that creates a
memfd for communication with the child processes [4].
* execute_directories() calls fork() and do_execute() [5] in order to
run each child process, providing them with the memfd descriptor in
order to gather their output.
* When a child process is executed, its context transitions from
sysadm_systemd_t to sysadm_t. The child then writes environment
variables to its output.
* The parent process (systemd --user) collects the environment variables
that have been written, and "consumes" the produced output in order to
override its environment variables.
[1] https://github.com/systemd/systemd/blob/v243/src/core/manager.c#L3836
[2] https://github.com/systemd/systemd/blob/v243/src/shared/exec-util.c#L413
[3] https://github.com/systemd/systemd/blob/v243/src/shared/exec-util.c#L213
[4] https://github.com/systemd/systemd/blob/v243/src/shared/serialize.c#L200
[5] https://github.com/systemd/systemd/blob/v243/src/shared/exec-util.c#L226
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
fs_read_cgroup_files() grants access to reading files and to following
symlinks (with "read_lnk_files_pattern($1, cgroup_t, cgroup_t)").
fs_rw_cgroup_files() does not include such a rule, which is needed in
order to transparently use symlinks such as /sys/fs/cgroup/cpu. This
access is currently denied, for example to "systemd --user" daemon:
type=AVC msg=audit(1569756917.537:242): avc: denied { getattr }
for pid=9710 comm="systemd" path="/sys/fs/cgroup/cpu" dev="tmpfs"
ino=9683 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:cgroup_t tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1569756917.537:242): arch=c000003e
syscall=262 success=no exit=-13 a0=ffffff9c a1=7ffc605b1f70
a2=7ffc605b1ea0 a3=100 items=0 ppid=1 pid=9710 auid=1000 uid=1000
gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000
fsgid=1000 tty=(none) ses=10 comm="systemd"
exe="/usr/lib/systemd/systemd"
subj=sysadm_u:sysadm_r:sysadm_systemd_t key=(null)
type=PROCTITLE msg=audit(1569756917.537:242):
proctitle=2F6C69622F73797374656D642F73797374656D64002D2D75736572
On this system (Debian 10), /sys/fs/cgroup/cpu is a symlink to
/sys/fs/cgroup/cpu,cpuacct.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
init_write_runtime_socket(systemd_user_session_type) is redundant with
init_dgram_send(systemd_user_session_type).
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Since systemd 242 (commit
6c8a2c6793),
systemd and its services read /proc/sys/kernel/osrelease in order to
detect whether they are running in Microsoft's WSL (Windows Subsystem
for Linux).
This leads to logs such as:
type=AVC msg=audit(1568445663.990:10): avc: denied { read } for
pid=401 comm="systemd-modules" name="osrelease" dev="proc" ino=13319
scontext=system_u:system_r:systemd_modules_load_t
tcontext=system_u:object_r:sysctl_kernel_t tclass=file permissive=1
type=AVC msg=audit(1568445663.990:10): avc: denied { open } for
pid=401 comm="systemd-modules" path="/proc/sys/kernel/osrelease"
dev="proc" ino=13319
scontext=system_u:system_r:systemd_modules_load_t
tcontext=system_u:object_r:sysctl_kernel_t tclass=file permissive=1
type=AVC msg=audit(1568445663.990:11): avc: denied { getattr } for
pid=401 comm="systemd-modules" path="/proc/sys/kernel/osrelease"
dev="proc" ino=13319
scontext=system_u:system_r:systemd_modules_load_t
tcontext=system_u:object_r:sysctl_kernel_t tclass=file permissive=1
Add kernel_read_kernel_sysctls() to services that read
/proc/sys/kernel/osrelease. These services have been identified by
running "grep osrelease < /var/log/audit/audit.log | audit2allow" on an
Arch Linux test system.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When resizing the X11 window of a terminal running sudo on a remote
Debian 10 system (through ssh), sudo forwards SIGWINCH to its children
(this behavior might be caused by using "Defaults use_pty" in
/etc/sudoers). This leads to the following audit logs:
type=AVC msg=audit(1567880108.988:13823): avc: denied { signal }
for pid=15670 comm="sudo" scontext=sysadm_u:sysadm_r:sysadm_sudo_t
tcontext=sysadm_u:sysadm_r:sysadm_t tclass=process permissive=0
type=SYSCALL msg=audit(1567880108.988:13823): arch=c000003e
syscall=62 success=no exit=-13 a0=ffffc2c9 a1=1c a2=ffffffff a3=100
items=0 ppid=15607 pid=15670 auid=1000 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=721 comm="sudo"
exe="/usr/bin/sudo" subj=sysadm_u:sysadm_r:sysadm_sudo_t key=(null)
type=PROCTITLE msg=audit(1567880108.988:13823):
proctitle=2F7573722F62696E2F7375646F002D73
The process tree (ps -ef, edited) on this remote system was:
LABEL UID PID PPID TTY CMD
system_u:system_r:sshd_t user 15519 15480 ? sshd: user@pts/5
sysadm_u:sysadm_r:sysadm_t user 15524 15519 pts/5 -zsh
sysadm_u:sysadm_r:sysadm_sudo_t root 15607 15524 pts/5 /usr/bin/sudo -s
sysadm_u:sysadm_r:sysadm_sudo_t root 15670 15607 pts/6 /usr/bin/sudo -s
sysadm_u:sysadm_r:sysadm_t root 15671 15670 pts/6 /usr/bin/zsh
The denied syscall was:
* syscall=62: int kill(pid_t pid, int sig)
* a0=ffffc2c9: pid = -15671 (process group of sudo's child)
* a1=1c: sig = 28 = SIGWINCH
Allow such a signal to be transmitted.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
udevadm trigger tries to read files under /sys/module/ that might not be
readable by root, for example:
--w------- 1 root root 4096 sep 5 17:06 /sys/module/snd_hda_codec_generic/uevent
We choose to allow it here because, according to Grift,
"the cap_dac_read_search could maybe be dontaudited, but then
cap_dac_override would have to be dontaudited as well.
cap_dac_read_search would also be triggered when you run `sudo udevadm
...` where pwd or/and oldpwd is ~"
type=PROCTITLE msg=audit(29/08/19 15:37:14.505:417) : proctitle=/bin/udevadm trigger --type=subsystems --action=add
type=PATH msg=audit(29/08/19 15:37:14.505:417) : item=0 name=/sys/module/snd_hda_codec_generic/uevent inode=17769 dev=00:13 mode=file,200 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(29/08/19 15:37:14.505:417) : cwd=/
type=SYSCALL msg=audit(29/08/19 15:37:14.505:417) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission non accordée) a0=0xffffff9c a1=0x7fff23710260 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=481 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
type=AVC msg=audit(29/08/19 15:37:14.505:417) : avc: denied { dac_override } for pid=481 comm=udevadm capability=dac_override scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:system_r:udevadm_t:s0 tclass=capability permissive=0
type=AVC msg=audit(29/08/19 15:37:14.505:417) : avc: denied { dac_read_search } for pid=481 comm=udevadm capability=dac_read_search scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:system_r:udevadm_t:s0 tclass=capability permissive=0
Signed-off-by: Laurent Bigonville <bigon@bigon.be>
Arch Linux installs Chromium in /usr/lib/chromium/ like Debian. Instead
of adding a new ifdef(`distro_arch') block, remove the restriction in
chromium.fc.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
