Bug#1013261: libselinux1 - restorecon fails with: No such file or directory
Package: libselinux1
Version: 3.4-1
SELinux: deactivated
Src:
https://salsa.debian.org/selinux-team/libselinux/-/blob/debian/src/selinux_restorecon.c
<https://salsa.debian.org/selinux-team/libselinux/-/blob/debian/src/selinux_restorecon.c>
Hey,
after today’s updated of „libselinux1“ to upstream version 3.4 in Debian
Testing we encounter issues while setting contexts using „setfiles“ which seems
to be related in
https://salsa.debian.org/selinux-team/libselinux/-/blob/debian/src/selinux_restorecon.c#L711-716
<https://salsa.debian.org/selinux-team/libselinux/-/blob/debian/src/selinux_restorecon.c#L711-716>
where „lgetfilecon_raw“ got replaced by the new function „fgetfilecon_raw“.
However, this seems to need an active SELinux environment for „fgetxattr“
function that needs /proc for „xattr“.
As a result this fails with (example):
/sbin/setfiles: Could not set context for /etc/hosts: No such file or directory
Example trace (another file):
openat(AT_FDCWD, "/etc/idmapd.conf", O_RDONLY|O_EXCL|O_NOFOLLOW|O_PATH) = 4
newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=171, ...}, AT_EMPTY_PATH) = 0
fgetxattr(4, "security.selinux", 0x55c65d6e3eb0, 255) = -1 EBADF (Bad file
descriptor)
fcntl(4, F_GETFL) = 0x22 (flags
O_RDONLY|O_NOFOLLOW|O_PATH)
getxattr("/proc/self/fd/4", "security.selinux", 0x55c65d6e3eb0, 255) = -1
ENOENT (No such file or directory)
write(2, "/sbin/setfiles: ", 16/sbin/setfiles: )= 16
write(2, "Could not set context for /etc/i"..., 71Could not set context for
/etc/idmapd.conf: No such file or directory) = 71
close(4)
While I can understand that most SELinux users would use this command(s) more
or less only on SELinux activated systems, there’re still some scenarios left
where this may be important like „chroots“ or similar.
Thanks,
gyptazy
Bug#1012756: Package: libselinux1 - SELINUXDEFAULT "targeted" should be "default"
Package: libselinux1 Version: 3.3-1+b2 Info: ‚libselinux1‘ doesn’t evaluate the correct ‚SELINUXDEFAULT‘ value. The current used default value points to a non existing path. Issue: When running SELinux on a freshly installed ‚Debian‘ (‚Stable‘, ‚Testing‘) in ‚enforcing‘ mode, ‚libselinux‘ seems to source the hardcoded var ‚SELINUXDEFAULT‘ (see also: https://salsa.debian.org/selinux-team/libselinux/-/blob/debian/src/selinux_config.c#L16). This is set to ‚targeted‘ and as far as I can see this won’t be re-evaluated at any time. However, ‚targeted‘ is the ‚RHEL‘ specific path and Debian uses ‚default‘ this may fail later when labels are evaluated (e.g. when starting ‚systemd-resolved‘). This is no issue when ‚SELinux‘ only runs in ‚permissive‘ mode, but when running in ‚enforcing‘ mode this will fail. Changing ‚SELINUXDEFAULT‘ to ‚SELINUXDEFAULT "default“‘, recompile ‚libselinux1‘ fixes this issues immediately. How to reproduce: • Use a Debian Stable or Testing minimal installation • Remove AppArmor (apt remove apparmor) • Install SELinux (apt-get install selinux-basics selinux-policy-default auditd) • Run ‚selinux-activate‘ (Keep in mind, this will only set SELinux to ‚permissive‘ mode, not ‚enforcing’) • Reboot (it will ‚relabel‘ during the boot) • Edit ‚/etc/selinux/config‘ an switch ‚SELINUX‘ from ‚permissive‘ to ‚enforcing‘ • Reboot • Now, you can reproduce the mentioned issue (‚systemctl start systemd-resolved‘) If you need further information or help for debugging, feel free to ask. I may also contribute a PR fixing this issue on Salsa. Thanks, gyptazy
Bug#1012755: Package: selinux-policy-default: Missing policies for e.g. systemd-resolved and bash
Package: selinux-policy-default
Version: 2:2.20220520-1
Info:
When running SELinux on a freshly installed ‚Debian‘ (‚Stable‘, ‚Testing‘) in
‚enforcing‘ mode, additional policies (e.g. for ‚bash‘ or ‚systemd-resolved‘)
are missing.
Issue(s):
• systemd-resolved
‚system-resolved‘ can not be started via systemd unit file. You will see errors
like ‚Failed to initialize SELinux labeling handle: No such file or directory‘.
Unfortunately, this is misleading in this case and is ‚libselinux-1‘ related
(reported within an additional bug report). However, there’s still an issue
which isn’t reported or logged in any case. Within the code you can see the
following block:
(optional base_optional_1526
(typeattributeset cil_gen_require selinux_config_t)
(dontaudit systemd_resolved_t selinux_config_t (dir (getattr open search)))
(dontaudit systemd_resolved_t selinux_config_t (file (ioctl read getattr
lock open)))
)
Which means that it is declared as ‚dontaudit‘. Removing the ‚dontaudit‘
attribute allows us fetch the missing rule and to create a policy for this:
AVC avc: denied { read } for pid=4016 comm="systemd-resolve" name="config"
dev="sda1" ino=531948 scontext=system_u:system_r:systemd_resolved_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file permissive=0
• /bin/bash: Permission denied
Trying to initialize a SSH session results directly in:
Linux testing 5.16.0-6-amd64 #1 SMP PREEMPT Debian 5.16.18-1 (2022-03-29) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Jun 13 08:22:29 2022 from 10.0.2.2
/bin/bash: Permission denied
Connection to 127.0.0.1 closed.
Luckily you can still use the regular console for logging in. However, this is
just to mention here and hasn’t been further analyzed.
How to reproduce:
• Use a Debian Stable or Testing minimal installation
• Remove AppArmor (apt remove apparmor)
• Install SELinux (apt-get install selinux-basics
selinux-policy-default auditd)
• Run ‚selinux-activate‘ (Keep in mind, this will only set SELinux to
‚permissive‘ mode, not ‚enforcing’)
• Reboot (it will ‚relabel‘ during the boot)
• Edit ‚/etc/selinux/config‘ an switch ‚SELINUX‘ from ‚permissive‘ to
‚enforcing‘
• Reboot
• Now, you can reproduce the mentioned issues (ssh login bash
permission, systemd-resolved)
If you need further information or help for debugging, feel free to ask.
Thanks,
gyptazy
Bug#996953: perl: make -j72 failing with a text file busy error
Hey Cedric,
I can confirm this issue when rebuilding Perl on powerful systems. Multiple
builds of ‚generate_uudmap.o‘ are
created during the compile time and at some point it fails with:
make -j88 […]
./generate_uudmap uudmap.h bitcount.h mg_data.h
6584make[3]: ./generate_uudmap: Text file busy
6585make[3]: *** [Makefile:329: bitcount.h] Error 127
As a result, I patched the ‚rules‘ file to run ‚dh_auto_build‘ with
‚--no-parallel‘ option.
You can find attached my patch file:
Subject: Avoid build failures on powerful machines
+++ perl-5.34.0/debian/rules
@@ -115,11 +115,11 @@
if [ "$*" = "shared" ]; then \
ln -s libperl.so.$(fullversion) build-$*/libperl.so.$(version); \
ln -s libperl.so.$(version) build-$*/libperl.so; \
- dh_auto_build --builddirectory=build-$* -- SHRPLDFLAGS='$$(LDDLFLAGS)
-Wl,-soname,libperl.so.$(version)'; \
+ dh_auto_build --no-parallel --builddirectory=build-$* --
SHRPLDFLAGS='$$(LDDLFLAGS) -Wl,-soname,libperl.so.$(version)'; \
elif [ "$*" = "debug" ]; then \
- dh_auto_build --builddirectory=build-$* -- perl; \
+ dh_auto_build --no-parallel --builddirectory=build-$* -- perl; \
else \
- dh_auto_build --builddirectory=build-$*; \
+ dh_auto_build --no-parallel --builddirectory=build-$*; \
fi
touch $@
Regards,
gyptazy
perl_debian_rules.patch
Description: Binary data
