Description of problem: This happens at boot, even after "fixfiles onboot", together with another 10 AVCs. SELinux is preventing ksmctl from 'add_name' accesses on the cartella run. ***** Plugin catchall (100. confidence) suggests ************************** Se ci credi ksmctl dovrebbe essere consentito add_name accesso al run directory per impostazione predefinita. Then si dovrebbe riportare il problema come bug. E' possibile generare un modulo di politica locale per consentire questo accesso. Do consentire questo accesso per ora eseguendo: # ausearch -c 'ksmctl' --raw | audit2allow -M my-$MODULE_NOME # semodule -X 300 -i miei-ksmctl.pp Additional Information: Source Context system_u:system_r:ksm_t:s0 Target Context system_u:object_r:sysfs_t:s0 Target Objects run [ dir ] Source ksmctl Source Path ksmctl Port <Sconosciuto> Host (removed) Source RPM Packages Target RPM Packages filesystem-3.16-2.fc36.x86_64 SELinux Policy RPM selinux-policy-targeted-36.9-1.fc36.noarch Local Policy RPM selinux-policy-targeted-36.9-1.fc36.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 5.17.11-300.fc36.x86_64 #1 SMP PREEMPT Wed May 25 15:04:05 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-05-29 19:59:57 CEST Last Seen 2022-05-29 19:59:57 CEST Local ID a6672d66-e7e4-44ce-bec7-4e2274e56ceb Raw Audit Messages type=AVC msg=audit(1653847197.728:233): avc: denied { add_name } for pid=1174 comm="ksmctl" name="run" scontext=system_u:system_r:ksm_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 Hash: ksmctl,ksm_t,sysfs_t,dir,add_name Version-Release number of selected component: selinux-policy-targeted-36.9-1.fc36.noarch Additional info: component: selinux-policy reporter: libreport-2.17.1 hashmarkername: setroubleshoot kernel: 5.17.11-300.fc36.x86_64 type: libreport
Davide, Could you please gather all the denials in full auditing mode? 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
*** Bug 2091418 has been marked as a duplicate of this bug. ***
*** Bug 2091416 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Description of the problem: =================== This happens at boot, even after "fixfiles onboot" here are the denials data in in full auditing mode. # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent ---- type=PROCTITLE msg=audit(03/06/2022 14:23:34.678:235) : proctitle=/usr/libexec/ksmctl start type=PATH msg=audit(03/06/2022 14:23:34.678:235) : item=1 name=/sys/kernel/mm/ksm/run inode=5435 dev=00:17 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(03/06/2022 14:23:34.678:235) : item=0 name=/sys/kernel/mm/ksm/ inode=5432 dev=00:17 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(03/06/2022 14:23:34.678:235) : cwd=/ type=SYSCALL msg=audit(03/06/2022 14:23:34.678:235) : arch=x86_64 syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x558a0ea3603f a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=1 pid=1153 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=ksmctl exe=/usr/libexec/ksmctl subj=system_u:system_r:ksm_t:s0 key=(null) type=AVC msg=audit(03/06/2022 14:23:34.678:235) : avc: denied { create } for pid=1153 comm=ksmctl name=run scontext=system_u:system_r:ksm_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=AVC msg=audit(03/06/2022 14:23:34.678:235) : avc: denied { add_name } for pid=1153 comm=ksmctl name=run scontext=system_u:system_r:ksm_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 type=AVC msg=audit(03/06/2022 14:23:34.678:235) : avc: denied { write } for pid=1153 comm=ksmctl name=ksm dev="sysfs" ino=5432 scontext=system_u:system_r:ksm_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 ---- hashmarkername: setroubleshoot kernel: 5.17.11-300.fc36.x86_64 package: selinux-policy-targeted-36.10-1.fc36.noarch reason: SELinux is preventing /usr/libexec/ksmctl from 'write' accesses on the cartella /sys/kernel/mm/ksm/run. type: libreport
After the upgrade to selinux-policy-36.10-1 this specific AVC changed to the one above. As you can see I included the denials in in full auditing mode as requested.
Similar problem has been detected: This AVC still happens at boot with selinux-policy-36.10-1 hashmarkername: setroubleshoot kernel: 5.17.11-300.fc36.x86_64 package: selinux-policy-targeted-36.10-1.fc36.noarch reason: SELinux is preventing ksmctl from 'create' accesses on the file run. type: libreport
Similar problem has been detected: This AVC still happens at boot with selinux-policy-36.10-1 hashmarkername: setroubleshoot kernel: 5.17.11-300.fc36.x86_64 package: selinux-policy-targeted-36.10-1.fc36.noarch reason: SELinux is preventing ksmctl from 'write' accesses on the cartella ksm. type: libreport
Test coverage for this bug exists in a form of PR: * https://src.fedoraproject.org/tests/selinux/pull-request/307 The PR waits for review.
Problem still persists on my f36 installation
FEDORA-2022-fd22b79a84 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd22b79a84
FEDORA-2022-fd22b79a84 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-fd22b79a84` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd22b79a84 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-320775eb9a has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-320775eb9a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-320775eb9a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-139ec288ca has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-139ec288ca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-139ec288ca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-139ec288ca has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.