Issues with GitHub actions not properly testing for SELinux related issues.

While working on [geerlingguy.nginx issue #265](https://github.com/geerlingguy/ansible-role-nginx/issues/265), I discovered an issue which is impossible to properly test using GitHub actions, and which is actually just the tip of the iceberg. With GitHub actions, even when running tests in a Rocky 9 container, because it is running on a Ubuntu server, which instead uses AppArmor instead of SELinux, it is impossible to see issues which would occur because of SELinux. This is because the kernel itself does not have SELinux support active, and the container relies upon the kernel for this feature. An example of this is where we have nginx creating a PID file with an incorrect SELinux file context when run with the `-t` option to verify the template generated configuration before copying it into its final location. Because the PID file is created with the incorrect context, when `geerlingguy.nginx` runs the next task in the role, `nginx` tries to open the PID file, is denied by SELinux as designed, and `nginx` fails to start. But, in the failure, the file gets deleted, and the next time the start of the `nginx` is attempted, the startup succeeds. Had SELinux been active, the testing would have caught it, but GitHub actions will not, because of this lack.

Unfortunately, as noted, this is just the tip of the iceberg, as far as testing is concerned. While tests could certainly be written to check things like file permissions and the SELinux file contexts, since file contexts are central to the Linux kernel and file systems like `extfs` and `xfs`, the true test for something like this would be to have run it in an environment where SELinux was in enforcing mode, where the task would have been seen to fail during development testing. Unfortunately, because of how it is designed, it is impossible to do this in GitHub at this time, since to install SELinux on Ubuntu, you have to reboot the machine to get it to activate, and that in turn causes GitHub to recycle the VM. Maybe, if enough of us were to raise this issue as a request for an SELinux enabled VM image, such as one running Rocky 9, or even a properly configured Ubuntu based image could be made available. As it is, the only way to test this situation, or any other SELinux related setup, is to run the tests on a VM or bare metal server provided by the developer at their own cost.

Because of how this affects an entire family of OS distros and involves a security feature widely used to secure systems around the world, such as at universities, federal agencies and labs, and even in the finance sector, this is probably worth adding at least prominently highlighted warning (if not adding something even stronger, given it involves security) to the book to Chapter 13 in the next update, and a similarly highlighted errata on the Errata page. It's too bad that even the e-book formats use a black & white icon for the warnings, instead of colored icons like green, yellow (or orange) and red, to make it even more clearly indicated (and stand out, like your graphic on page 367, showing the testing spectrum).

As an FYI, I started a discussion over on the GitHub Community under actions, to suggest that they add SELinux enabled images in addition to the current Ubuntu/AppArmor images, due to those industries mentioned relying heavily upon SELinux.

Start by locating Chapter 13 and the Errata page in the book sources, then review how existing security or testing warnings are presented. Confirm the scope with the issue's request, and consider the work complete when both locations prominently explain that GitHub Actions does not test SELinux-enforcing environments.

Written by the indexing model from the issue text.