Enabling SELinux on Fedora 33 or another qube

I wanted to learn about SELinux and tried enabling it on a fedora-33 standalone qube, “fedora-SELinux-test”.

I tried
sudo nano /etc/selinux/config
, but the file didn’t exist. I did a
sudo dnf whatprovides /etc/selinux/config
, which prompted me to sudo dnf install selinux-policy.
Then I tried adding permissive or enforcing after SELinux= in the file and then getenforce told me Disabled, setenforce 1 told me setenforce: SELinux is disabled.
I then did
sudo dnf whatprovides sestatus
and then
sudo dnf install policycoreutils-py*
, but that didn’t help. I rebooted each time I made a change. I tried to make the qube HVM as well in case there was a problem with kernel and XEN interacting, but I don’t know how that works.

The “Managing qube kernels” documentation says the kernels are provided by dom0 and I shouldn’t modify kernel options within the qube. OK, so in dom0 I did
qvm-prefs fedora-SELinux-test
and for kernelopts I only see "nopat’. I couldn’t find what kernelopts to add for SELinux support or even that’s the way I should proceed.

I don’t know much about SELinux so I can’t troubleshoot the problem myself. I searched for similar problems, but there was nothing qubes-related or anything else that helped me.

Has anyone successfully enabled SELinux in Qubes? How? If it’s even possible, how should I proceed? I feel like I’m missing some critical information without which I can’t proceed.

I believe the actual kernel is provided by Dom0 and it has no SELinux support compiled in. You would have to compile your own kernel with SE enabled.

If I had the time I would have done this just for the chance to set SE in permissive mode and connect the avc logging to a intrusion detection system. Kind of like a tripwire it could notify you if someone even starts poking around on your system.

The intruder after all will have SU root privileges by default but an enforcing SE could add actual protections to the system via security context. A context coming from Dom0 would be different from one that is from a persistent hook installed from a network intrusion. sudo can’t discriminate the difference but SE could stop it dead in its tracks via its context.

It sure would be nice if the devs would compile a development kernel with SE so that some of the real security geeks could figure out ways to make qubes even more secure. I just don’t have the luxury of studying the qubes build system just to play with it.

How can I compile my own kernel so that the only different between the newly compiled kernel and the one currently used in Fedora is the addition of SELinux support? Is compiling the kernel to get the standard Fedora template for Qubes documented? I imagine there are already some changes to the kernel used in the Fedora template, so if I get a vanilla kernel and compile it myself, it would miss those Qubes-specific changes?

I haven’t compiled kernels myself, but would like to try, so I’d appreciate any ideas on how to start.

Logging would be nice, but I how would you do it exactly? Something like this thread about a separate logging qube? Or will you log in the same qube?

The intruder after all will have SU root privileges by default

Because of passwordless sudo or because it’s generally easy to escalate to root, even if password protected?

Note: If you go to a qubes settings, and then go to “advanced”, you can select which version of the kernel you want to use with the qube. (I agree it would be nice to have a SE option there)
As @slcoleman was saying, this kernel is on dom0, not inside the fedora qube as one might expect.

Going to dom0 and doing dnf search qubes | grep kernel shows kernel-qubes-vm.x86_64 , so this is what you are looking to compile yourself.

This page might have something helpful twards that goal:

Not a complete answer, but that should help you

logs get generated in the appVM qube itself. However when you reboot, the logs dissapear. If you want to keep logs one option is to just make it a standalone VM instead of a appVM. If you want it stored in another qube, then yes, the above link is for you (or will be when it’s done :slight_smile:

I’m reading the docs, but just to clarify - if I want a specific kernel in a qube, I have to install this kernel in dom0 as well?

If yes, do I have to additionally change the kernel that’s used in dom0 to the newer one? If it’s not a newer version, but the same version as the one used in dom0, just with different options, will I have to use those same kernel with the same options in dom0?

For example, I want to use the same 5.4.98-1.fc25 kernel for my Fedora 33 qubes, but with SELinux enabled. Can I compile that kernel on another Qubes machine and use it on the first machine? Will I have to restart Qubes to use the newer kernel?

Lots of noob questions, I know, but I’ve never done anything like this so far.

Yes. Basic idea: Use whatever qube you want to build it. Then you install the kernel in dom0 (which will end up in /var/lib/qubes/vm-kernels/). The individual qubes do not need a copy just to use it (unless you are using HVM for some reason).

The part that will take some work will be the “installing your new kernel in dom0” part. There is probably a “list of kernels to make available to individual qubes” that it needs to be registered with somewhere, meaning just copying the kernel to /var/lib/qubes/vm-kernels/ probably wont work. Best bet would probably be to use the standard build procedure (or a portion of it) to build a .rpm file.

Also, when you attempt to copy the file into dom0 you will find that just copying any file to dom0 is a challenge. You can either use How to copy from dom0 | Qubes OS or you can set up your own repository for the package you generated.

Also of note, I think that fedora comes with selinux aready enabled meaning that the qubes team disabled it.

Also of possible use to you: The options you are looking for in the kernel config probably all start with the string “SECURITY_SELINUX”

Hey, I found that the procedure is already documented. If you want all the paches of the qubes team, then you want to see the “installing differnt vm kernel based on dom0 kernel” section of:

If you just want to use a kernel without the qubes team patches, then you want “Using kernel installed in the VM” (that users hvm mode)

I wrote slightly better version of instructions. It basically explains the install procedure a bit better then the docs I pointed you to before, however how you are supposed to compile it without installing a bunch of packages on dom0 is not obvious.

The new version is here:

While looking at the .config file, it looks like SELINUX might already be enabled in the kernel, and may just need to be enabled in the distribution.


user@debian-11:/sys/kernel$ zgrep -i selinux /proc/config.gz 

So you probably just need to enable it from inside the qube somehow. (or maybe a boot parameter?)

1 Like

Wow, thanks a lot for the instructions! When I have free time, I’ll definitely give it a go.

Some more tips:
Selinux boot parameters (search term: CONFIG_DEFAULT_SECURITY_SELINUX (I.E. the one selinux kernel config that is not set)), might be “selinux=1 security=selinux”

Also, it looks like boot parameters are managed with qvm-prefs, so for example:

qvm-prefs {qubename} kernelopts

would show you the current kernelopts. let’s say it said it’s currently using the kernel options “nopat”. Then:

qvm-prefs {qubename} kernelopts "nopat selinux=1 security=selinux"

might be all you need.

Np. I’m rooting for you.

SELinux is neat for several reasons, one being that it can reduce attack surface. For example, SELinux is run on all modern android systems, and is used to remove permission to call any calls that are only there for backwards compatibility with old libraries and you already know your libraries are new enough that they no longer use them.

Also SELinux supposedly can be used for labeling the security category of data. A discussion about trying to decide & label the security category of a entire qube is here: Picking a system for selecting colors/security labels for qubes . It might be neat if someday the selinux security category (I.E. security label) of individual files could be automatically coordinated with the qube security category somehow.

Come back tell us how it goes after you try it out. I’d be very interested to hear your results.

After changing the kernelopts like you said, then installing policycureutils-python-utils and selinux-policy (not sure I need both, but the latter provides the /etc/selinux/config file) and changing “disabled” to “permissive”, sudo getenforce says “Permissive”, not “Disabled” as before!

I’m still interested in being able to compile a custom kernel, though, so I posted my progress (or lack thereof) in the other thread you made.

Thanks so much again for the help, who knew it would be that easy to enable SELinux. Of course, I’m anticipating some headaches when actually configuring SELinux later, but so far so good. :slight_smile: