Description of problem: This is a follow-on after the improvements made by bug #2114498. A few aspects of the SELinux policy still seem to prevent xenstored from starting. Version-Release number of selected component (if applicable): selinux-policy-targeted-36.14-1.fc36.noarch How reproducible: Every time Steps to Reproduce: 1. Boot the kernel under Xen as Dom0 2. Observe that xenstored does not start Additional info: Running "setenforce 0" allows xenstored to start. SELinux seems to be denying the use of prlimit in /etc/xen/scripts/launch-xenstore. I found that xenstored will start if I modify /etc/xen/scripts/launch-xenstore to avoid using prlimit, albeit without the protection that prlimit provides. Here are the audit logs produced by booting when SELinux is in permissive mode: ---- type=AVC msg=audit(09/09/2022 12:36:19.021:147) : avc: denied { remount } for pid=529 comm=(chronyd) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=1 ---- type=AVC msg=audit(09/09/2022 12:36:19.106:152) : avc: denied { setrlimit } for pid=538 comm=prlimit scontext=system_u:system_r:xenstored_t:s0 tcontext=system_u:system_r:xenstored_t:s0 tclass=process permissive=1 ---- type=SERVICE_START msg=audit(09/09/2022 12:36:19.538:153) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='unit=xenstored comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success' ---- type=SERVICE_START msg=audit(09/09/2022 12:36:19.588:154) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='unit=xenconsoled comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success' ---- type=SERVICE_START msg=audit(09/09/2022 12:36:47.198:231) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='unit=xendomains comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
Hi, The first one is already an addressed problem, cab you gather more information for the second one ? 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 today
This is what I got with selinux-policy-36.15-1.fc36.noarch and a freshly-relabeled filesystem: ---- type=AVC msg=audit(09/23/2022 14:22:37.160:152) : avc: denied { remount } for pid=523 comm=(chronyd) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=AVC msg=audit(09/23/2022 14:22:37.174:154) : avc: denied { remount } for pid=525 comm=(d-logind) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=AVC msg=audit(09/23/2022 14:22:39.150:173) : avc: denied { remount } for pid=578 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=AVC msg=audit(09/23/2022 14:30:04.471:330) : avc: denied { remount } for pid=1616 comm=(emd-oomd) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=AVC msg=audit(09/23/2022 14:39:27.156:149) : avc: denied { remount } for pid=521 comm=(chronyd) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=AVC msg=audit(09/23/2022 14:39:27.323:155) : avc: denied { remount } for pid=524 comm=(d-logind) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=AVC msg=audit(09/23/2022 14:39:30.761:206) : avc: denied { remount } for pid=592 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=PROCTITLE msg=audit(09/23/2022 14:49:27.986:148) : proctitle=(chronyd) type=PATH msg=audit(09/23/2022 14:49:27.986:148) : item=0 name=/proc/self/fd/4 inode=1 dev=00:21 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:xenstored_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(09/23/2022 14:49:27.986:148) : cwd=/ type=SYSCALL msg=audit(09/23/2022 14:49:27.986:148) : arch=x86_64 syscall=mount success=no exit=EACCES(Permission denied) a0=0x0 a1=0x7ffdc3b97410 a2=0x0 a3=MS_RDONLY|MS_REMOUNT|MS_BIND items=1 ppid=1 pid=527 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=(chronyd) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(09/23/2022 14:49:27.986:148) : avc: denied { remount } for pid=527 comm=(chronyd) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=PROCTITLE msg=audit(09/23/2022 14:49:28.139:154) : proctitle=(d-logind) type=PATH msg=audit(09/23/2022 14:49:28.139:154) : item=0 name=/proc/self/fd/4 inode=1 dev=00:21 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:xenstored_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(09/23/2022 14:49:28.139:154) : cwd=/ type=SYSCALL msg=audit(09/23/2022 14:49:28.139:154) : arch=x86_64 syscall=mount success=no exit=EACCES(Permission denied) a0=0x0 a1=0x7ffdc3b97400 a2=0x0 a3=MS_RDONLY|MS_REMOUNT|MS_BIND items=1 ppid=1 pid=529 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=(d-logind) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(09/23/2022 14:49:28.139:154) : avc: denied { remount } for pid=529 comm=(d-logind) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0 ---- type=PROCTITLE msg=audit(09/23/2022 14:49:28.646:155) : proctitle=prlimit --nofile=1073741816 /usr/sbin/xenstored --pid-file /var/run/xen/xenstored.pid type=SYSCALL msg=audit(09/23/2022 14:49:28.646:155) : arch=x86_64 syscall=prlimit64 success=no exit=EACCES(Permission denied) a0=0x0 a1=0x7 a2=0x55fa676e15b0 a3=0x0 items=0 ppid=532 pid=536 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=prlimit exe=/usr/bin/prlimit subj=system_u:system_r:xenstored_t:s0 key=(null) type=AVC msg=audit(09/23/2022 14:49:28.646:155) : avc: denied { setrlimit } for pid=536 comm=prlimit scontext=system_u:system_r:xenstored_t:s0 tcontext=system_u:system_r:xenstored_t:s0 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(09/23/2022 14:49:28.710:156) : proctitle=/usr/bin/bash /etc/xen/scripts/launch-xenstore type=PATH msg=audit(09/23/2022 14:49:28.710:156) : item=0 name=/proc// inode=1 dev=00:14 mode=dir,555 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:proc_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(09/23/2022 14:49:28.710:156) : cwd=/ type=SYSCALL msg=audit(09/23/2022 14:49:28.710:156) : arch=x86_64 syscall=openat success=no exit=ENOENT(No such file or directory) a0=AT_FDCWD a1=0x55a9bd4ad600 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=1 ppid=1 pid=532 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=launch-xenstore exe=/usr/bin/bash subj=system_u:system_r:xenstored_t:s0 key=(null) type=AVC msg=audit(09/23/2022 14:49:28.710:156) : avc: denied { dac_override } for pid=532 comm=launch-xenstore capability=dac_override scontext=system_u:system_r:xenstored_t:s0 tcontext=system_u:system_r:xenstored_t:s0 tclass=capability permissive=0 ---- type=PROCTITLE msg=audit(09/23/2022 14:49:30.713:174) : proctitle=(ostnamed) type=PATH msg=audit(09/23/2022 14:49:30.713:174) : item=0 name=/proc/self/fd/4 inode=1 dev=00:21 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:xenstored_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(09/23/2022 14:49:30.713:174) : cwd=/ type=SYSCALL msg=audit(09/23/2022 14:49:30.713:174) : arch=x86_64 syscall=mount success=no exit=EACCES(Permission denied) a0=0x0 a1=0x7ffdc3b973f0 a2=0x0 a3=MS_RDONLY|MS_REMOUNT|MS_BIND items=1 ppid=1 pid=575 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=(ostnamed) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(09/23/2022 14:49:30.713:174) : avc: denied { remount } for pid=575 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=0
Adding the setrlimit permission, not adding dac_override.
FEDORA-2022-0c59a07653 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c59a07653
FEDORA-2022-0c59a07653 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-0c59a07653` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c59a07653 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-0c59a07653 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
About a year ago I installed Xen on fc36, and it is now up-to-date fc38. At the time I had to apply two local semodules for xenstored and dom0 to initialize properly at boot. I tried disabling those and only one of them was fixed, on September 26, 2022: https://github.com/fedora-selinux/selinux-policy/commit/26067f0549584df9a507084226c048ab13c31ec8 The other one is still not fixed. Here is the avc denial message I get at boot: Aug 10 00:24:40 fedora audit[1076]: AVC avc: denied { map } for pid=1076 comm="xenstored" path="/proc/xen/xsd_kva" dev="xenfs" ino=5 scontext=system_u:system_r:xenstored_t:s0 tcontext=system_u:object_r:xenfs_t:s0 tclass=file permissive=0 Aug 10 00:24:40 fedora launch-xenstore[1055]: Starting /usr/sbin/xenstored... Aug 10 00:24:40 fedora launch-xenstore[1076]: FATAL: Failed to initialize dom0: Permission denied Aug 10 00:24:40 fedora xenstored[1076]: Failed to initialize dom0: Permission denied Other relevant messages: Aug 10 00:24:42 fedora setroubleshoot[1153]: failed to retrieve rpm info for path '/proc/xen/xsd_kva': ... Aug 10 00:24:44 fedora setroubleshoot[1153]: SELinux is preventing xenstored from map access on the file /proc/xen/xsd_kva. For complete SELinux messages run: sealert -l 3241eb95-a07b-4c70-a38a-941bc6777822 Aug 10 00:24:44 fedora setroubleshoot[1153]: SELinux is preventing xenstored from map access on the file /proc/xen/xsd_kva. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow domain to can mmap files Then you must tell SELinux about this by enabling the 'domain_can_mmap_files' boolean. Do setsebool -P domain_can_mmap_files 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that xenstored should be allowed map access on the xsd_kva file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'xenstored' --raw | audit2allow -M my-xenstored # semodule -X 300 -i my-xenstored.pp I applied the second fix because it seemed like the more targeted fix, and the my-xenstored.te file audit2allow generated is: [user@fedora ~]$ cat selinux/my-xenstored.te module my-xenstored 1.0; require { type xenfs_t; type xenstored_t; class file map; } #============= xenstored_t ============== #!!!! This avc can be allowed using the boolean 'domain_can_mmap_files' allow xenstored_t xenfs_t:file map; [user@fedora ~]$ So I think another fix needs to be applied to policy/modules/contrib/xen.te in the selinux-policy package to fix this problem. Thanks.