Comment # 24
on bug 1213721
from LTC BugProxy
------- 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