Standard Fedora’s SELinux policy is used there, with unconfined “user” account. The local “user” can still do everything, but having SELinux enabled makes it possible to use it for targeted cases (previously enabling SELinux in a template in enforcing mode made it essentially unbootable). Those targeted cases are both about specific services (there are several services shipped with SELinux policy, for example we use it also for extra sandboxing of the inter-qube file copy service), but also various sandboxing tools like bubblewrap, podman/docker etc. They can use SELinux to create stronger sandboxes.
In short: the local user still can do everything (as it already has access to all the data), but SELinux gives an extra tool to isolate some processes from becoming that all-powerful local user.
As for Debian, it doesn’t fully support SELinux out of the box. But it does support AppArmor (also under qubes) which can be used for similar purpose (although it’s a weaker tool for that…).