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>
The pattern /opt/brother/Printers(.*/)?inf(/.*)? matches the content of
directories such as /opt/brother/Printersinf/, which seems buggy. On
several systems, /opt/brother/Printers/ is a directory that contains
directories named as printer models.
Add a "/" before "(.*/)?" in order to make sure subdirectories of
/opt/brother/Printers named "inf" are matched by the pattern.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
/usr/lib/jvm/java(.*/)bin(/.*)? uses misleading parentheses around
".*/". In some cases, a pattern with (.*/) is a mispelling to (.*/)?,
but not here (/usr/lib/jvm/javabin/ never exists).
Moreover, using .* here is right, as the pattern matches the content of
subdirectories of /usr/lib/jvm/ which names are prefixed by java. More
precisely, the pattern matches for example:
- programs in /usr/lib/jvm/java-10-openjdk/bin
- programs in /usr/lib/jvm/java-8-openjdk/jre/bin
In the end, the pattern does not have any error, but the parentheses are
misleading. Remove them.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In libraries.fc:
- "(/.*?)" is very likely a misspelling for (/.*)?
- "sidecars/*" with "--" as file type is very likely a misspelling for
sidecars/.+, in order to match files that are shared libraries.
- "/opt/netbeans(.*/)?jdk" matches "/opt/netbeansjdk", which is buggy.
In Apache NetBeans 11.1 downloaded from
https://netbeans.apache.org/download/nb111/nb111.html, there are files
such as profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so.
Several websites document installing NetBeans in directories such as
/opt/netbeans-11.1/, so the installed .so files are probably installed in
/opt/netbeans-11.1/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so.
There is thus an issue with the current pattern:
/opt/netbeans(.*/)?jdk.*/linux/.+\.so(\.[^/]*)*
This pattern requires "/linux/" in the path, not "/linux-amd64/".
As this pattern was introduced in 2007 by commit 02d968c581 ("trunk:
several fc updates from dan."), consider it as outdated and remove it.
If the .so files in /opt/netbeans/ really need a label such as
textrel_shlib_t, a file pattern will need to be written with less issues
than the one which is removed.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
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>
On Debian, haveged fails to start with "haveged: Couldn't open random
device: Permission denied". strace shows:
openat(AT_FDCWD, "/dev/random", O_RDWR) = -1 EACCES (Permission denied)
audit.log has:
type=AVC msg=audit(1566048720.132:1338): avc: denied { search }
for pid=20235 comm="haveged" name="/" dev="tmpfs" ino=76666
scontext=system_u:system_r:entropyd_t
tcontext=system_u:object_r:tmpfs_t tclass=dir permissive=0
With systemd, /dev is a temporary filesystem (tmpfs_t), so haveged needs
the search permission to it in order to open /dev/random. Use the
newly-added interface to allow this access.
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>
When a service is configured with PrivateDevices=yes, its /dev directory
has label tmpfs_t. This requires allowing more accesses in order for the
service to use /dev.
This is related to https://github.com/SELinuxProject/refpolicy/pull/61
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>
Chris PeBenito
Dominick Grift
Nicolas Iooss