/dev/ipmi is labeled, but no interfaces exist to grant access to the device.
Adding interface for read/write access, I'm not sure of read-only access is usefull. ipmitool seems to only read and write
type=AVC msg=audit(1581618155.319:786): avc: denied { read write } for pid=4498 comm="ipmitool" name="ipmi0" dev="devtmpfs" ino=10460 scontext=system_u:system_r:ipmi_t:s0 tcontext=system_u:object_r:ipmi_device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1581618155.319:786): avc: denied { open } for pid=4498 comm="ipmitool" path="/dev/ipmi0" dev="devtmpfs" ino=10460 scontext=system_u:system_r:ipmi_t:s0 tcontext=system_u:object_r:ipmi_device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1581618155.320:787): avc: denied { ioctl } for pid=4498 comm="ipmitool" path="/dev/ipmi0" dev="devtmpfs" ino=10460 ioctlcmd=6910 scontext=system_u:system_r:ipmi_t:s0 tcontext=system_u:object_r:ipmi_device_t:s0 tclass=chr_file permissive=1
This exception goes back 14 years to commit 85c20af3c1 and 11a0508ede.
The tts exception is covered by a distro agnostic rule further up, and the udev rule doesn't even work (it's supposed to be /lib/udev/ not /usr/lib/udev on gentoo) so I seriously doubt anyone is going to miss them.
Signed-off-by: Vilgot <Vilgot@fredenberg.xyz>
Required for example to start/stop systemd-journal-flush.service
which moves the journal storage back and forth between tmpfs and
permanent storage.
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
fifo_files inherited from domains allowed to change role to sysadm_r.
This enables to do e.g. 'echo "..." | sudo -r sysadm_r command' from a
staff_u:staff_r:staff_t context
the permissions to write the wireless device in order to
prevent a possible Denial of Service (DoS) attack from an
unprivileged process bringing down the wireless interfaces.
Only administrative users can now enable/disable the wireless
interfaces, while normal users can only read their status.
Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
---
policy/modules/kernel/devices.if | 18 ++++++++++++++++++
policy/modules/system/userdomain.if | 3 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
auditd can halt the system for several reasons based on configuration.
These mostly revovle around audit partition full issues. I am seeing
the following denials when attempting to halt the system.
Jan 12 03:38:48 localhost audispd: node=localhost type=USER_AVC msg=audit(1578800328.122:1943): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/poweroff.target" cmdline="/sbin/init 0" scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:power_unit_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jan 12 03:38:48 localhost audispd: node=localhost type=USER_AVC msg=audit(1578800328.147:1944): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/poweroff.target" cmdline="/sbin/init 0" scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:power_unit_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jan 12 04:44:54 localhost audispd: node=localhost type=AVC msg=audit(1578804294.103:1923): avc: denied { getattr } for pid=6936 comm="systemctl" path="/run/systemd/system" dev="tmpfs" ino=45 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:systemd_unit_t:s0 tclass=dir permissive=1
v2 - use optional rather than ifdef
v3 - fix order
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Systemd has ConditionPath.*, ConditionFile.* and ConditionDir* which
are used to check various path/file/directory to control starting a
service. But this requires getattr permissions on the types.
Example denials that fit the problem.
The first example is from lvm where accessing config file.
type=AVC msg=audit(1575427946.229:1624): avc: denied { getattr } for
pid=1 comm="systemd" path="/etc/lvm/lvm.conf" dev="dm-0" ino=51799
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:lvm_etc_t:s0 tclass=file permissive=0
This second example is from chronyd, but it is happening becuase I added
the conditional in a drop-in file.
type=AVC msg=audit(1575427959.882:1901): avc: denied { getattr } for
pid=1 comm="systemd" path="/etc/chrony.conf" dev="dm-0" ino=53824
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:chronyd_conf_t:s0 tclass=file permissive=1
v3 - rework to not use interface and allow getattr for all files
Signed-off-by: Dave Sugar <dsugar@tresys.com>
libfuse 3.0 renamed fusermount to fusermount3 in order to allow both
libfuse 2 and libfuse 3 to be installed together:
695e45a4de
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
On a Debian 10 test virtual machine, when installing packages adds a
group, the following AVC occurs:
type=USER_AVC msg=audit(1578863991.588:575): pid=381 uid=104
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=LookupDynamicUserByName dest=org.freedesktop.systemd1
spid=13759 tpid=1 scontext=unconfined_u:unconfined_r:groupadd_t
tcontext=system_u:system_r:init_t tclass=dbus permissive=1
exe="/usr/bin/dbus-daemon" sauid=104 hostname=? addr=? terminal=?'
Allow groupadd to use nss-systemd, which calls DBUS method
LookupDynamicUserByName().
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
systemd's Name Service Switch (NSS) module provides UNIX user and group
name resolution for dynamic users and groups allocated through options
such as DynamicUser= in systemd unit files, according to its man page,
https://github.com/systemd/systemd/blob/v244/man/nss-systemd.xml.
If systemd compiled without NOLEGACY, commit
24eccc3414
("nss-systemd,user-util: add a way how synthesizing "nobody" can be
turned off") implemented a way to tweak nss-systemd's behavior by
checking whether /etc/systemd/dont-synthesize-nobody exists. Allow this
access.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When an unconfined user runs wine, there is an issue because
wine_domtrans() causes a transition to unconfined_u:unconfined_r:wine_t
without unconfined_r being associated with wine_t:
type=SELINUX_ERR msg=audit(1579963774.148:1047):
op=security_compute_sid
invalid_context="unconfined_u:unconfined_r:wine_t"
scontext=unconfined_u:unconfined_r:wine_t
tcontext=system_u:object_r:wine_exec_t tclass=process
This is fixed with "roleattribute unconfined_r wine_roles;", which is
provided by interface wine_run().
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Looking at all audit versions in gentoo (2.8.5 to 2.6.4) every single one of them has `var/log/audit` as a directory and not as a file.
Tested on gentoo.
example for querying their state, enabling and/or disabling
them using userspace tools such as "rfkill" from util-linux).
See also:
https://wireless.wiki.kernel.org/en/users/documentation/rfkill
Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
---
policy/modules/system/userdomain.if | 1 +
1 file changed, 1 insertion(+)
Add interface similar to files_mountpoint() and add a conditional which
allows mount on non_security_file_type.
Signed-off-by: Chris PeBenito <chpebeni@linux.microsoft.com>
The implementation for NETLINK_FIREWALL and NETLINK_IP6_FW protocols
was removed from the kernel in commit
d16cf20e2f2f13411eece7f7fb72c17d141c4a84 ("netfilter: remove ip_queue
support") circa Linux 3.5. Consequently, kernels >= 3.5 should never
perform permission checks on these classes although they remained
defined in the SELinux kernel classmap until the netlink classes
were updated by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c6d2e9bde1c1c87a7ead806f8f5e2181d41a652
circa Linux v4.2.
Removing these class definitions would break legacy userspace that relies
upon stable values for the userspace security class definitions since it
will perturb those values by removing classes that preceded them. dbus-daemon
in particular is known to break if its dbus class changes at runtime,
which could occur upon a policy reload that removes these classes.
Fixing this requires ensuring that dbus-daemon looks up the appropriate
class value on each use or upon policy reload, via userspace interfaces
such as selinux_check_access(), string_to_security_class(), and/or
selinux_set_callback(SELINUX_CB_POLICYLOAD, ...) with a callback function
that remaps the class value if needed. Other userspace policy enforcers
are believed to have been updated in recent versions but older versions
may break upon such a change.
Hence, this change renames these classes with obsolete_ prefixes and
removes all rules referencing them from refpolicy, thereby preserving
the class numbering for subsequent classes while making it clear that
these classses are no longer meaningful for modern kernels.
This change does however create a potential compatibility break for
kernels < 3.5, since the policy will cease to define the kernel class
names and therefore the kernel will handle permission checks on the
class based on the handle_unknown setting in policy. For most
Linux distributions, this will default to allow and therefore avoid
breaking userspace but will fail open. For kernels < 2.6.33 (i.e.
the dynamic class/perm discovery support), the presence of a class
in policy with the same number but a different name than the kernel
class will cause the policy load to fail entirely.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
entrypoint and execute_no_trans permissions are only ever checked by the
kernel to regular files. They were added to the chr_file class when
execmod was added (which can be checked on chr_file) to ensure that it
was assigned the same value as for the file class, since the kernel code
always checked FILE__EXECMOD. However, the policy definitions are not
necessary since the kernel and policy values have been decoupled ever
since dynamic class/perm support was introduced and further with the
move of execmod to the common definitions, they were not even needed
in the kernel.
These were removed from the kernel's classmap by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b424485abe2b16580a178b469917a7b6ee0c152a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove unused permission definitions from SELinux.
Many of these were only ever used in pre-mainline
versions of SELinux, prior to Linux 2.6.0. Some of them
were used in the legacy network or compat_net=1 checks
that were disabled by default in Linux 2.6.18 and
fully removed in Linux 2.6.30.
The corresponding classmap declarations were removed from the
mainline kernel in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42a9699a9fa179c0054ea3cf5ad3cc67104a6162
Permissions never used in mainline Linux:
file swapon
filesystem transition
tcp_socket { connectto newconn acceptfrom }
node enforce_dest
unix_stream_socket { newconn acceptfrom }
Legacy network checks, removed in 2.6.30:
socket { recv_msg send_msg }
node { tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send dccp_recv dccp_send }
netif { tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send dccp_recv dccp_send }
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As adding attribute fixed_disk_raw_read to a type cannot occur in a
conditional statement, create a new interface that takes a tunable as
parameter to allow a dangerous access conditionally.
Signed-off-by: Nicolas Iooss <nicolas.iooss_git@polytechnique.org>
When using libvirt to manage virtual machines, libvirt_leaseshelper
wants to:
* read /etc/libnl/classid
* list the content of /sys/devices/system/node/ in order to read files
such as /sys/devices/system/node/node0/meminfo
* use getsched
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Since systemd 244, systemd can parse EFI variable
SystemdOptions-8cf2644b-4b0b-428f-9387-6d876050dc67 like /proc/cmdline
in order to find options. systemd's NEWS file [1] states:
systemd will also read configuration options from the EFI variable
SystemdOptions. This may be used to configure systemd behaviour when
modifying the kernel command line is inconvenient, but configuration
on disk is read too late, for example for the options related to
cgroup hierarchy setup. 'bootctl systemd-efi-options' may be used to
set the EFI variable.
In practice, all callers of log_parse_environment() read this EFI
variable, because:
* log_parse_environment() is a macro which is expanded to
log_parse_environment_realm(LOG_REALM) [2].
* log_parse_environment_realm() calls proc_cmdline_parse() when being
use in system daemons [3].
* proc_cmdline_parse() always calls systemd_efi_options_variable() [4].
* systemd_efi_options_variable() reads SystemdOptions variable [5].
For SELinux, this means that every domain with attribute
systemd_log_parse_env_type wants to read an EFI variable. Allow this
access.
[1] https://github.com/systemd/systemd/blob/v244/NEWS#L18-L23
[2] https://github.com/systemd/systemd/blob/v244/src/basic/log.h#L84
[3] https://github.com/systemd/systemd/blob/v244/src/basic/log.c#L1116
[4] https://github.com/systemd/systemd/blob/v244/src/basic/proc-cmdline.c#L122
[5] https://github.com/systemd/systemd/blob/v244/src/basic/efivars.c#L242
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
dirmngr needs to listen and accept on /run/user/1000/gnupg/S.dirmngr
type=AVC msg=audit(1554175286.968:2720907): avc: denied { accept } for pid=15692 comm="dirmngr" path="/run/user/1000/gnupg/S.dirmngr" scontext=staff_u:staff_r:dirmngr_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:dirmngr_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0
Signed-off-by: Jason Zaman <jason@perfinion.com>
CryFS (https://www.cryfs.org/) is a software that can be run by non-root
users that have access to /dev/fuse. Its command is directly used to
mount a directory ("/usr/bin/cryfs basedir mountpoint"), like command
"mount". Unmounting a mountpoint is done with "fusermount -u
mountpoint", /usr/bin/fusermount being a setuid-root program labeled
mount_exec_t.
EncFS (https://www.arg0.net/encfs) is a similar software that has been
considered insecure since a security audit in 2014 found vulnerabilities
that are not yet fixed (like https://github.com/vgough/encfs/issues/9).
gocryptfs (https://nuetzlich.net/gocryptfs/) is a similar software that
has been inspired by EncFS.
Allow users with role sysadm to use all these projects.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In order to be able to invoke /usr/bin/mount, /usr/bin/fusermount, etc.
callers need to be able to search /usr/bin. Otherwise, such denials are
recorded:
type=AVC msg=audit(1576534518.220:1320): avc: denied { search }
for pid=24067 comm="cryfs" name="bin" dev="vda1" ino=524829
scontext=sysadm_u:sysadm_r:cryfs_t tcontext=system_u:object_r:bin_t
tclass=dir permissive=0
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
I'm seeing the following error while starting rsyslog:
Nov 17 02:01:38 localhost rsyslogd: cannot create '/run/systemd/journal/syslog': Permission denied [v8.24.0-41.el7_7.2]
Nov 17 02:01:38 localhost rsyslogd: imuxsock does not run because we could not aquire any socket [v8.24.0-41.el7_7.2]
Nov 17 02:01:38 localhost rsyslogd: activation of module imuxsock failed [v8.24.0-41.el7_7.2]
With the following denials:
type=AVC msg=audit(1573958708.773:1896): avc: denied { create } for pid=2347 comm="rsyslogd" name="syslog" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:syslogd_runtime_t:s0 tclass=sock_file permissive=1
type=AVC msg=audit(1573958708.773:1897): avc: denied { setattr } for pid=2347 comm="rsyslogd" name="syslog" dev="tmpfs" ino=19368 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:syslogd_runtime_t:s0 tclass=sock_file permissive=1
Signed-off-by: Dave Sugar <dsugar@tresys.com>
When alsactl is running as a daemon with systemd, it sets its process
priority to be nice to other processes. When stopping the service, it's
signaling to itself that it needs to exit.
----
time->Sun Oct 6 11:59:59 2019
type=AVC msg=audit(1570355999.755:43): avc: denied { setsched } for pid=794 comm="alsactl" scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:system_r:alsa_t:s0 tclass=process permissive=1
----
time->Sun Oct 6 11:59:59 2019
type=AVC msg=audit(1570355999.755:44): avc: denied { getsched } for pid=794 comm="alsactl" scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:system_r:alsa_t:s0 tclass=process permissive=1
----
time->Sun Oct 6 12:07:26 2019
type=AVC msg=audit(1570356446.747:292): avc: denied { signal } for pid=3585 comm="alsactl" scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:system_r:alsa_t:s0 tclass=process permissive=1
Signed-off-by: Laurent Bigonville <bigon@bigon.be>
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>
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>
All callers of consoletype_exec() put it in an optional_policy() block
but portage. This makes consoletype module mandatory when module portage
is loaded, even when consoletype is not installed.
Fix this issue by introducing an optional_policy() block.
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>
