Bug 2231508

Description of problem:
The xenstored service is required for Linux running under Xen as dom0. The xenstored process requires map permission on the /proc/xen/xsd_kva file, but SELinux denies xenstored the required permission.

Version-Release number of selected component (if applicable):
version 38.22-1.fc38 of the selinux-policy.noarch package

How reproducible:
Always.

Steps to Reproduce:
1. Update fc38 system on bare metal to latest packages (Xen dom0 is not expected to work in a VM).

2. Ensure the default SELinux policy is in place (run restorecon if necessary, use enforcing mode, etc.)

3. Install the xen-runtime, xen-hypervisor, and xen-tools packages, if not already installed. These xen packages depend on certain grub2 modules, like multiboot2, being installed also for the system to be able to boot Fedora as dom0. My experience is that the process for installing Xen and getting it configured properly is not always smooth, so this step might be difficult for users not familiar with running Fedora Linux as a Xen dom0. When I installed Xen packages on Fedora for the first time about a year ago, on fc36, they did not work out of the box but once they are configured correctly, they are rock-solid stable. YMMV.

4. After you think the Xen packages and their dependencies are installed correctly, reboot and choose the option to boot Fedora with Xen from the grub menu. Currently, on my box, this is the 'Fedora, with Xen 4.17.1 and Linux 6.4.9-200.fc38.x86_64' option on the grub menu.
 
5. The system should boot and you should be able to login to a terminal on the console. Maybe also you can login to a GUI DE using a display manager such as gdm, but honestly I never tried it with Xen which is more appropriate on a headless server, and if you have trouble booting Fedora with Xen and the gdm / gnome system, try it with a minimal installation without gdm / gnome or any other GUI stuff like X or Wayland.

6. Everything seems OK, except when you try to run commands to get information about the hypervisor or start a Xen guest. For example, the ordinary output of the command to list the running Xen guests should be as follows after installing Xen and rebooting Fedora with Xen:

[user@fedora ~]$ sudo xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  2048     4     r-----     434.8
[user@fedora ~]$

Actual results:
When running sudo xl list, the command hangs with no output, and you have to ctrl-C to get back to a shell prompt:

[user@fedora ~]$ sudo xl list

Expected results:
sudo xl list and other xl commands to control the Xen hypervisor and manage Xen guests should work properly instead of hanging.

Additional info:
For additional context, this bug has been present ever since I installed Xen on Fedora almost a year ago, when fc36 was the latest stable release. I have worked around the bug by installing the local SELinux policy module that setroubleshoot suggested (this can be found from journalctl or systemctl status commands) and never got around to verifying it is still a bug and reporting it until now. More details about the actual local SELinux policy module that fixed the problem for me locally can be found here:

https://bugzilla.redhat.com/show_bug.cgi?id=2125693#c7

That bug was reported against fc36 and is now closed, presumably because fc36 is EOL. Therefore, I open this new bug against fc38.

Long story short:

The fix is probably just to add the following to the xen policy module in the selinux-policy package:

allow xenstored_t xenfs_t:file map;

I have not tested this fix and am content to just use the local SELinux policy module I have been using for over a year which adds that permission to xenstored to map xenfs_t files using a local module instead of using the xen module provided by the selinux-policy package, but I am willing to test any updates to the selinux-policy package that the maintainers of that package might propose as a fix on my box and report my results here.

I think the additional context I have provided strongly suggests this bug also applies to rawhide and fc39, but I do not use those systems and have not verified those systems are also affected by this bug.