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>
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>
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>
Patterns using this have a small issue:
/opt/Adobe/Reader.?/Reader/intellinux
The issue is that the dot can also match a slash. A bettern pattern
would be:
/opt/Adobe/Reader[^/]?/Reader/intellinux
In this specific case, the intent is to match digits (like
/opt/Adobe/Reader9). Use [0-9] for this.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
This patch is based on comments from previous a patch to
remove the many uses of kernel_dgram_send() and incorporate
it into logging_send_syslog_msg().
v2 - enclose in ifdef for redhat
v3 - rebase this patch on e41def136a
Signed-off-by: Dave Sugar <dsugar@tresys.com>
This is the update I have made based on suggestions for the previous
patches to add a udev_run interface. This adds the new domain udevadm_t
which is entered from /usr/bin/udevadm.
It seems to meet the needs that I have, but there are some things to
note that are probably important.
1) There are a few systemd services that use udevadm during startup.
I have granted the permisssions that I need based on denials I was
seeing during startup (the machine would fail to start without the
permisions).
2) In the udev.fc file there are other binaries that I don't have on a
RHEL7 box that maybe should also be labeled udevadm_exec_t.
e.g. /usr/bin/udevinfo and /usr/bin/udevsend
But as I don't have those binaries to test, I have not updated the
type of that binary.
3) There are some places that call udev_domtrans that maybe should now
be using udevadm_domtrans - rpm.te, hal.te, hotplug.te. Again,
these are not things that I am using in my current situation and am
unable to test the interactions to know if the change is correct.
Other than that, I think this was a good suggestion to split udevadm
into a different domain.
Only change for v4 is to use stream_connect_pattern as suggested.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
I'm seeing a denial for udev to map /etc/udev/hwdb.bin.
This creates and uses a new interface to allow the needed
permission for udev.
type=AVC msg=audit(1551886176.948:642): avc: denied { map } for pid=5187 comm="systemd-udevd" path="/etc/udev/hwdb.bin" dev="dm-1" ino=6509618 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_hwdb_t:s0 tclass=file permissive=1
Updated from previous to create a new interface.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Nicolas Iooss
Chris PeBenito
Laurent Bigonville
Alexander Miroshnichenko
Chris PeBenito
Sugar, David