Can't enforce SELinux in qubes template VM.

[kaizsv]

Qubes OS version (e.g., R3.1): R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable): jessie

---

Expected behavior:

$ getenforce
Enforcing

Actual behavior:

$ getenforce
Disabled

Steps to reproduce the behavior:

I successfully installed a "jessie" template VM in qubes OS from qubes-builder following steps in Archlinux Template. And want to enable SELinux in the template VM

$ sudo vim /etc/selinux/config
# set SELINUX=enforcing
$ sudo selinux-active
$ sudo selinux-config-enforcing

After rebooted the jessie using getenforce while it was not working.

$ sudo check-selinux-installation
getfilecon:  getfilecon(/proc/1) failed
SELinux is not enabled.
Could not read the domain of PID 1.
The directories /sys/fs/selinux and /selinux are missing.

I google several selinux and debian guides, like
https://wiki.debian.org/SELinux/Setup
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=16738,
still not work. I'm not sure that is there any way to enable SELinux in template VM?

[rtiangha]

You're (probably) missing a step.

You also need to pass along kernel options that activates selinux.

First, view the options that your app vm already has:

qvm-prefs -l <app-vm> kernelopts

(it'll probably say something like 'nopat', unless it's a netvm or usbvm in which case it'll have additional options)

Then you need to set it to use selinux by adding the security=selinux and selinux=1 kernel options:

qvm-prefs -s <app-vm> kernelopts "nopat security=selinux selinux=1"

And then boot up the VM.

That should do it (at least, it does on a Fedora template).

If you wanted to use Apparmor instead, you'd need to replace the selinux options with security=apparmor and apparmor=1

[rtiangha]

You're (probably) missing a step.

You also need to pass along kernel options that activates selinux.

First, view the options that your app vm already has:

qvm-prefs -l <app-vm> kernelopts

(it'll probably say something like 'nopat', unless it's a netvm or usbvm in which case it'll have additional options)

Then you need to set it to use selinux by adding the security=selinux and selinux=1 kernel options:

qvm-prefs -s <app-vm> kernelopts "nopat security=selinux selinux=1"

And then boot up the VM.

That should do it (at least, it does on a Fedora template).

If you wanted to use Apparmor instead, you'd need to replace the selinux options with security=apparmor and apparmor=1

[kaizsv]

Thank you for your respond. I make a stupid mistake so have to reinstall my template VM.
I'll try it later. Thanks for you information!

[kaizsv]

Thank you for your respond. I make a stupid mistake so have to reinstall my template VM.
I'll try it later. Thanks for you information!

[adrelanos]

rtiangha:

You also need to pass along kernel options that activates selinux.

Right. In dom0. Not inside VMs.

[adrelanos]

rtiangha:

You also need to pass along kernel options that activates selinux.

Right. In dom0. Not inside VMs.

[rtiangha]

adrelanos:

Right. In dom0. Not inside VMs.

Really? That's not been my experience. The only way I've been able to activate those security features in VMs has been through kernel options; nothing I've ever done inside the VM was enough. And I think that's intentional? Because if you mess up your internal configuration, then you risk having a VM not booting, which means you can't easily fix it afterwards (because it doesn't boot).

As for dom0, unless you're good at writing selinux rules, you'll probably not want to do that as the machine won't boot due to permission issues with the default policies.

And as an aside for anyone keeping score, I've found that the default targeted policy works well on Fedora 23 and 24 templates using both the 4.4 and 4.8 (found in the unstable repository) kernels. Using the 4.8 kernel won't boot those Fedora VMs using the default MLS policy (xenstore permission error). And neither policy at its defaults seems to work with a upconverted 24 template to Fedora 25 using the qubes packages in the current-testing repository. I don't know what effect those kernel and policy combinations would have on a Debian template.

[rtiangha]

adrelanos:

Right. In dom0. Not inside VMs.

Really? That's not been my experience. The only way I've been able to activate those security features in VMs has been through kernel options; nothing I've ever done inside the VM was enough. And I think that's intentional? Because if you mess up your internal configuration, then you risk having a VM not booting, which means you can't easily fix it afterwards (because it doesn't boot).

As for dom0, unless you're good at writing selinux rules, you'll probably not want to do that as the machine won't boot due to permission issues with the default policies.

And as an aside for anyone keeping score, I've found that the default targeted policy works well on Fedora 23 and 24 templates using both the 4.4 and 4.8 (found in the unstable repository) kernels. Using the 4.8 kernel won't boot those Fedora VMs using the default MLS policy (xenstore permission error). And neither policy at its defaults seems to work with a upconverted 24 template to Fedora 25 using the qubes packages in the current-testing repository. I don't know what effect those kernel and policy combinations would have on a Debian template.

[unman]

Right. In dom0. Not inside VMs.

Really? That's not been my experience. The only way I've been able to activate those security features in VMs has been through kernel options; nothing I've ever done inside the VM was enough. And I think that's intentional? Because if you mess up your internal configuration, then you risk having a VM not booting, which means you can't easily fix it afterwards (because it doesn't boot).

I think that's what adrelanos was saying - that you pass the options to the qube from dom0. Which was implicit in your post.

[unman]

Right. In dom0. Not inside VMs.

Really? That's not been my experience. The only way I've been able to activate those security features in VMs has been through kernel options; nothing I've ever done inside the VM was enough. And I think that's intentional? Because if you mess up your internal configuration, then you risk having a VM not booting, which means you can't easily fix it afterwards (because it doesn't boot).

I think that's what adrelanos was saying - that you pass the options to the qube from dom0. Which was implicit in your post.

[rtiangha]

Ah, got it. Sorry; obviously need more coffee this morning.

[rtiangha]

Ah, got it. Sorry; obviously need more coffee this morning.

[unman]

@kaizsv selinux support isn't great in jessie, but stretch works fine. I found that it helped to increase qrexec_timeout in qvm-prefs for the first boot after installation of the selinux packages. Otherwise you shouldn't find any problems if you follow @rtiangha 's advice

[unman]

@kaizsv selinux support isn't great in jessie, but stretch works fine. I found that it helped to increase qrexec_timeout in qvm-prefs for the first boot after installation of the selinux packages. Otherwise you shouldn't find any problems if you follow @rtiangha 's advice

[kaizsv]

Thanks a lot!
I still have problem in debian-8 and jessie.
But it work fine in my fedora-23, I'll keep focus on fedora rather than debian.
Thanks!

[kaizsv]

Thanks a lot!
I still have problem in debian-8 and jessie.
But it work fine in my fedora-23, I'll keep focus on fedora rather than debian.
Thanks!