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>
I think these may have been adopted from the old Red Hat targeted policy (that model only had unconfined users)
Some aspect to note:
1. The ssh_sysadm_login boolean now applies to unconfined_t as well
2. remotelogin only allows unpriv logins
The rshd module also calls unconfined_shell_domtrans() but I ignored that one because that policy currently does not have support for manual transitions with pam_selinux.
Signed-off-by: Dominick Grift <dac.override@gmail.com>
When /etc/sudoers contains "Defaults use_pty", sudo creates a new
pseudo-pty when running a command. This is currently denied from
a sysadm_u session:
type=AVC msg=audit(1567807315.843:13300): avc: denied { read write
} for pid=5053 comm="sudo" name="ptmx" dev="devtmpfs" ino=1108
scontext=sysadm_u:sysadm_r:sysadm_sudo_t
tcontext=system_u:object_r:ptmx_t tclass=chr_file permissive=0
As it seems logical for the newly-created pty to be labeled
user_devpts_t, use userdom_create_user_pty() to allow this.
Then, a new denial appears:
type=AVC msg=audit(1567808670.441:13341): avc: denied { setattr }
for pid=30256 comm="sudo" name="9" dev="devpts" ino=12
scontext=sysadm_u:sysadm_r:sysadm_sudo_t
tcontext=sysadm_u:object_r:user_devpts_t tclass=chr_file
permissive=0
type=SYSCALL msg=audit(1567808670.441:13341): arch=c000003e
syscall=92 success=no exit=-13 a0=563c5aac5f80 a1=0 a2=5
a3=fffffffffffff874 items=0 ppid=20934 pid=30256 auid=1000 uid=0
gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000
tty=pts4 ses=687 comm="sudo" exe="/usr/bin/sudo"
subj=sysadm_u:sysadm_r:sysadm_sudo_t key=(null)
On x86-64, syscall 92 is chown(). Allow this access with
userdom_setattr_user_ptys().
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
systemd-modules-load.service needs to read file
/sys/module/${MODULE}/initstate for each ${MODULE} defined in
/etc/modules-load.d/. These files are labeled sysfs_t.
This fixes:
type=AVC msg=audit(1567804818.331:138713): avc: denied { read }
for pid=31153 comm="systemd-modules" name="initstate" dev="sysfs"
ino=14778 scontext=system_u:system_r:systemd_modules_load_t
tcontext=system_u:object_r:sysfs_t tclass=file permissive=0
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
On a Debian system, when installing a package which provides a kernel
module with DKMS, the module is compiled and depmod is executed with a
command line that looks like:
depmod -a 4.19.0-5-amd64 -F /boot/System.map-4.19.0-5-amd64
This obviously requires depmod to read System.map. Otherwise, the
following events are logged to audit.log:
type=AVC msg=audit(1567802614.408:138551): avc: denied { search }
for pid=12090 comm="depmod" name="boot" dev="vda1" ino=262145
scontext=sysadm_u:sysadm_r:kmod_t tcontext=system_u:object_r:boot_t
tclass=dir permissive=0
type=AVC msg=audit(1567802670.132:138555): avc: denied { read }
for pid=14210 comm="depmod" name="System.map-4.19.0-5-amd64"
dev="vda1" ino=262148 scontext=sysadm_u:sysadm_r:kmod_t
tcontext=system_u:object_r:system_map_t tclass=file permissive=1
type=AVC msg=audit(1567802670.132:138555): avc: denied { open }
for pid=14210 comm="depmod" path="/boot/System.map-4.19.0-5-amd64"
dev="vda1" ino=262148 scontext=sysadm_u:sysadm_r:kmod_t
tcontext=system_u:object_r:system_map_t tclass=file permissive=1
type=AVC msg=audit(1567802670.136:138556): avc: denied { getattr }
for pid=14210 comm="depmod" path="/boot/System.map-4.19.0-5-amd64"
dev="vda1" ino=262148 scontext=sysadm_u:sysadm_r:kmod_t
tcontext=system_u:object_r:system_map_t tclass=file permissive=1
and depmod fails, which makes apt fails with:
wireguard.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/4.19.0-5-amd64/updates/dkms/
depmod...(bad exit status: 1)
[...]
Error! Problems with depmod detected. Automatically uninstalling
this module.
DKMS: Install Failed (depmod problems). Module rolled back to built
state.
dpkg: error processing package wireguard-dkms (--configure):
installed wireguard-dkms package post-installation script
subprocess returned error exit status 6
[...]
Errors were encountered while processing:
wireguard-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
WireGuard is a fast, modern, secure VPN tunnel, according to
https://www.wireguard.com/. In order to install it, the mostly
documented way consists in building and installing an out-of-tree kernel
module and using userland tools to configure this module (wg and
wg-quick).
* WireGuard is like "ip": the userland tool communicates with the kernel
module through a netlink socket.
* WireGuard is like "iptables": there is no daemon, but some
distributions ship systemd units that restores a WireGuard
configuration when started.
* WireGuard is like other services: its configuration files are in /etc,
and it can use /run and /tmp.
Create a new policy module which handles all of this.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When bringing up a Wireguard interface with "wg-quick up wg0" from a
sysadm_u:sysadm_r:sysadm_t session, "systemd --user" spams the logs
with this event repeated between 100 and 200 times per second:
type=AVC msg=audit(1567798007.591:138076): avc: denied { read }
for pid=711 comm="systemd"
scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=sysadm_u:sysadm_r:sysadm_systemd_t
tclass=netlink_kobject_uevent_socket permissive=0
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
WeeChat is an extensible IRC client: https://weechat.org/
* Label WeeChat program and configuration file like other IRC clients
* Allow WeeChat to create a pipe in ~/.weechat/weechat_fifo
* Allow WeeChat to read /proc/sys/crypto/fips_enabled
* Allow WeeChat to use a Unix datagram socket with its forked children
* Allow other accesses
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When starting tmux on Debian, the following audit log appears:
type=AVC msg=audit(1567781766.314:820): avc: denied {
execute_no_trans } for pid=6686 comm=746D75783A20736572766572
path="/usr/lib/x86_64-linux-gnu/utempter/utempter" dev="vda1"
ino=545302 scontext=sysadm_u:sysadm_r:sysadm_screen_t
tcontext=system_u:object_r:lib_t tclass=file permissive=0
/usr/lib/x86_64-linux-gnu/utempter/utempter is indeed labeled as
system_u:object_r:lib_t, which is wrong.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Since apt 1.8.1 (more precisely since commit
60cc44d160),
apt calls D-Bus method "Inhibit" of interface
"org.freedesktop.login1.Manager" in order to prevent a shutdown from
happening while installing software.
The call from apt to systemd-logind was already allowed through
unconfined_dbus_send(apt_t), but not the reply, which triggered the
following audit log:
type=USER_AVC msg=audit(1567780304.196:651): pid=287 uid=105
auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t
msg='avc: denied { send_msg } for msgtype=method_return
dest=:1.137 spid=290 tpid=29557
scontext=system_u:system_r:systemd_logind_t
tcontext=sysadm_u:sysadm_r:apt_t tclass=dbus permissive=0
exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?'
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Some recent modifications added patterns in .fc files for programs in
/usr/sbin without adding the patterns for /usr/bin. On Arch Linux, where
/usr/sbin is a symlink to /usr/bin, such patterns are never matched.
Add the missing patterns.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Chris PeBenito
Nicolas Iooss
Laurent Bigonville
Dominick Grift