https://bugzilla.suse.com/show_bug.cgi?id=1213721 https://bugzilla.suse.com/show_bug.cgi?id=1213721#c24 --- Comment #24 from LTC BugProxy <bugproxy@us.ibm.com> --- ------- Comment From rajanikanth.ha@in.ibm.com 2023-10-12 00:48 EDT------- (In reply to comment #15)

The new versions of kdump (since v1.9.0) save the initrd in /var/lib/kdump/initrd and maintain a symlink to the kernel the initrd has been build for in /var/lib/kdump/kernel.

E.g.: dhcp198:~ # ls -lZ /var/lib/kdump/ total 35476 -rw-------. 1 root root system_u:object_r:kdump_var_lib_t:s0 36322984 Jul 27 14:28 initrd lrwxrwxrwx. 1 root root system_u:object_r:kdump_var_lib_t:s0 40 Jul 27 14:28 kernel -> /usr/lib/modules/6.3.9-5-default/vmlinuz

SELinux blocks the following of the symlink during kdump service start.

audit2allow suggests: allow kdump_t kdump_var_lib_t:lnk_file read;

To me (a comlete SELinux noob) this makes sense and indeed creating and loading a module with audit2allow -M kdump-fix < /var/log/audit/audit.log semodule -i kdump-fix.pp fixes the problem.

Operating System: openSUSE MicroOS

SELinux status, mode and policy name: <TODO> SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33

SELinux policy version and repository: <TODO> dhcp198:~ # rpm -qa|grep selinux-pol selinux-policy-20230622-2.1.noarch selinux-policy-targeted-20230622-2.1.noarch

The software (incl. version) that is affected by the SELinux issue and the error message: kdump SELinux Audit log: dhcp198:~ # ausearch -ts today -m avc ---- time->Thu Jul 27 14:26:15 2023 type=PROCTITLE msg=audit(1690467975.028:134): proctitle=2F7362696E2F6B65786563002D70002F7661722F6C69622F6B64756D702F6B65726 E656C002D2D617070656E643D2072642E74696D656F75743D36302072642E72657472793D3435 2071756965742073797374656D642E73686F775F7374617475733D79657320636F6E736F6C653 D74747953302C31313532303020636F6E73 type=SYSCALL msg=audit(1690467975.028:134): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffd0d633da7 a2=0 a3=0 items=0 ppid=4833 pid=4834 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1690467975.028:134): avc: denied { read } for pid=4834 comm="kexec" name="kernel" dev="sda3" ino=48130 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:kdump_var_lib_t:s0 tclass=lnk_file permissive=0 ---- time->Thu Jul 27 14:26:15 2023 type=PROCTITLE msg=audit(1690467975.032:135): proctitle=2F7362696E2F6B65786563002D70002F7661722F6C69622F6B64756D702F6B65726 E656C002D2D617070656E643D2072642E74696D656F75743D36302072642E72657472793D3435 2071756965742073797374656D642E73686F775F7374617475733D79657320636F6E736F6C653 D74747953302C31313532303020636F6E73 type=SYSCALL msg=audit(1690467975.032:135): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffc2c117daa a2=0 a3=0 items=0 ppid=4835 pid=4836 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1690467975.032:135): avc: denied { read } for pid=4836 comm="kexec" name="kernel" dev="sda3" ino=48130 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:kdump_var_lib_t:s0 tclass=lnk_file permissive=0 ---- time->Thu Jul 27 14:26:15 2023 type=PROCTITLE msg=audit(1690467975.032:136): proctitle=2F7362696E2F6B65786563002D70002F7661722F6C69622F6B64756D702F6B65726 E656C002D2D617070656E643D2072642E74696D656F75743D36302072642E72657472793D3435 2071756965742073797374656D642E73686F775F7374617475733D79657320636F6E736F6C653 D74747953302C31313532303020636F6E73 type=SYSCALL msg=audit(1690467975.032:136): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffc2c117daa a2=0 a3=0 items=0 ppid=4835 pid=4836 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1690467975.032:136): avc: denied { read } for pid=4836 comm="kexec" name="kernel" dev="sda3" ino=48130 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:kdump_var_lib_t:s0 tclass=lnk_file permissive=0

Hi, thanks for opening the bug. I'm currently looking into what the best solution could be.

What does kdump need to do with the kernel that is pointed to by the symlink? Will it need to just read it or more than that?

yes, just read it. See: https://github.com/openSUSE/kdump/blob/master/init/load.sh First, on lines 373 and 374 it is tested that the two files (initrd and kernel) in /var/lib/kdump exist. On line 202 they are passed to kexec. In between that, mkdumprd is called that compares timestamps and possibly regenerates /var/lib/kdump/initrd but that does not seem to be blocked by SELinux.

As noted in Comment #0, audit2allow suggested "allow kdump_t kdump_var_lib_t:lnk_file read;" and that works.

Can you give me the steps to reproduce this on MicroOS? I am not familiar with kdump, and starting it the naive way (systemctl start kdump) does not do the right thing SELinux-wise (that's perhaps an issue on its own...).

(In reply to Filippo Bonazzi from comment #3)

...

Can you give me the steps to reproduce this on MicroOS? I am not familiar with kdump, and starting it the naive way (systemctl start kdump) does not do the right thing SELinux-wise (that's perhaps an issue on its own...).

But that seems like the correct way to reproduce. What does it to? In my testing it fails with exit code 6, which comes from the above mentioned "[[ -f "${kdump_kernel}" ]] || exit 6" line, because the test fails due to SELinux.

Executing `systemctl start kdump` results in this AVC: ``` time->Fri Jul 28 12:23:45 2023 type=AVC msg=audit(1690539825.110:98): avc: denied { read } for pid=1173 comm="load.sh" name="kernel" dev="vda4" ino=31389 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:kdump_var_lib_t:s0 tclass=lnk_file permissive=0 ```

which is not the same one as has been reported above, as the source context is system_u:system_r:init_t:s0.

On my test system (a fresh microos VM) systemd (init_t) is executing load.sh but is not transitioning to kdump_t (unsurprisingly, since load.sh and its siblings are not labeled kdump_exec_t). I cannot reproduce the issue as has been reported above.

I suspect the issue to be much deeper than it appears, and the simple fix I came up with to fix the issue reported above (https://gitlab.suse.de/fbonazzi/selinux-policy/-/commit/ 64532e474ab287818a337258fe12579535294d20) is not sufficient.

After extensive discussion, we agreed to just release the simple fix and defer a more complete analysis and fix to a later time.

I will submit this fix to Factory, but it will need to get submitted to ALP and SLE Micro as well.

FTR, the selinux-policy fix now allows kexec to read the kdump kernel via the /var/lib/kdump/kernel symlink.

kdump's load.sh still fails on this test: [[ -f /var/lib/kdump/kernel ]] || exit 6 At this point load.sh runs under init_t and SELinux denies following the link.

Since the selinux-policy for this is hard, I temporarily worked around this by this hack: https://github.com/openSUSE/kdump/commit/ c01eb10ccf123d76bd1bd71d48ccdbbc6160dc8c Replacing the built-in [[ test with /bin/test results in the symlink being dereferenced in a different SELinux context which works. Committed as kdump-1.9.5 to Kernel:Kdump submitted to Factory in SR 1101210.

------- Comment From bwiedemann+obsbugzillabot@suse.com 2023-07-28 15:15:04------- This is an autogenerated message for OBS integration: This bug (1213721) was mentioned in https://build.opensuse.org/request/show/1101210 Factory / kdump

Could you please also submit this to ALP?

Submitted in https://build.suse.de/request/show/306321

I'm currently trying to make the kdump test in openQA work on ALP. I was able to reproduce this issue but also that https://build.suse.de/request/show/307424 fixes it (see my notes in https://progress.opensuse.org/issues/136028#note-4 for details).

This is likely affecting SLE Micro as well - although I ran into other problems there as well so I created a separate ticket: bsc#1215717

SLE Micro is actually not affected. I just did a mistake when doing my testing.

*** Bug 1215731 has been marked as a duplicate of this bug. ***

Hi, I am unable to disable SELinux in SLES16 ALP, The service "audit2allow " is not present and from transactional-update am unable to get this. Please let me know how to disable in SLES16 ALP Thanks -- You are receiving this mail because: You are on the CC list for the bug.