SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 selinux-policy-40.9-1.fc40.noarch time->Mon Jan 22 08:03:09 2024 type=PROCTITLE msg=audit(1705928589.770:127): proctitle=2F7362696E2F616765747479002D6F002D70202D2D205C75002D2D6E6F636C656172002D006C696E7578 type=SYSCALL msg=audit(1705928589.770:127): arch=c000003e syscall=16 success=yes exit=0 a0=0 a1=5457 a2=7ffda0a903e0 a3=8 items=0 ppid=1 pid=819 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="agetty" exe="/usr/sbin/agetty" subj=system_u:system_r:getty_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1705928589.770:127): avc: denied { checkpoint_restore } for pid=819 comm="agetty" capability=40 scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=capability2 permissive=1 Reproducible: Always Steps to Reproduce: 1.Reboot a machine 2. 3.
Bruno, It does not reproduce out of the box with aggety from util-linux-2.39.3-2.fc40.x86_64. Do you know what is the triggering condition? Does it fail in something?
I have util-linux-2.39.3-2.fc40.x86_64 installed, the problem we hit after we installed a kernel and rebooted.
I can reproduce it after installation of kernel-6.8.0-0.rc0.20240119git9d1694dc91ce.9.fc40.x86_64. @omosnace I am quite baffled now. This is the first time I see checkpoint_restore in action and neither trace nor commit https://github.com/torvalds/linux/commit/74858abbb1032222f922487fd1a24513bbed80f9 gave me a lead. The service does not seem to fail or report an issue. No more denials in permissive mode. agetty 921 [000] 301.072967: avc:selinux_audited: requested=0x100 denied=0x100 audited=0x10> ffffffff9572501d avc_audit_post_callback+0x20d ([kernel.kallsyms]) ffffffff9572501d avc_audit_post_callback+0x20d ([kernel.kallsyms]) ffffffff9574e665 common_lsm_audit+0x2b5 ([kernel.kallsyms]) ffffffff957261f3 slow_avc_audit+0xb3 ([kernel.kallsyms]) ffffffff9572b618 cred_has_capability.isra.0+0x118 ([kernel.kallsyms]) ffffffff9571f341 security_capable+0x41 ([kernel.kallsyms]) ffffffff95122cbb ns_capable+0x2b ([kernel.kallsyms]) ffffffff95a43a3d tty_mode_ioctl+0x24d ([kernel.kallsyms]) ffffffff95a3bd76 tty_ioctl+0x126 ([kernel.kallsyms]) ffffffff9549cc14 __x64_sys_ioctl+0x94 ([kernel.kallsyms]) ffffffff960244a6 do_syscall_64+0x86 ([kernel.kallsyms]) ffffffff962000ea entry_SYSCALL_64_after_hwframe+0x6e ([kernel.kallsyms]) 7fc9eb3b9a2d __GI___ioctl+0x3d (/usr/lib64/libc.so.6) 55a93b378e7a [unknown] (/usr/sbin/agetty)
This is due to commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0f25b8992345aa5f113da2815f5add98738c611. It seems a bit odd to put this under CAP_CHECKPOINT_RESTORE, since it is apparently used for more than just checkpoint-restore... But since there is still fallback to CAP_SYS_ADMIN, I'm not sure if we have a strong argument to revert it. Since CAP_SYS_ADMIN likely makes more sense for agetty's use case, I'm in favor of resolving this in the policy by dontauditing checkpoint_restore and letting it be allowed via CAP_SYS_ADMIN as before. Same goes for bug 2260116.
*** Bug 2260116 has been marked as a duplicate of this bug. ***
*** Bug 2263324 has been marked as a duplicate of this bug. ***
*** Bug 2263634 has been marked as a duplicate of this bug. ***
*** Bug 2264841 has been marked as a duplicate of this bug. ***
*** Bug 2264934 has been marked as a duplicate of this bug. ***
*** Bug 2265444 has been marked as a duplicate of this bug. ***
*** Bug 2265579 has been marked as a duplicate of this bug. ***
*** Bug 2265688 has been marked as a duplicate of this bug. ***
*** Bug 2265784 has been marked as a duplicate of this bug. ***
*** Bug 2266580 has been marked as a duplicate of this bug. ***
*** Bug 2267435 has been marked as a duplicate of this bug. ***