Enabling SELinux makes it so domains cannot start

[t4777sd]

Qubes OS version:

4.0 utilizing default Fedora 28 templates that are fully updated

Steps to reproduce the behavior:

1. Edit /etc/selinux/config and enable selinux in the TemplateVM and restart the TemplateVM:

SELINUX=enforcing SELINUXTYPE=targeted

2. Add the following kernel params to the AppVM domain where SELinux should be enabled:

qvm-prefs --set kernelopts "nopat security=selinux selinux=1"

3. Start the AppVM

qvm-start

Expected behavior:

Expected that the AppVM can boot with SELinux enabled especially because SELinux is enabled by default in fedora.

Actual behavior:

The VM does not start and eventually will need to be killed.

• Note: the behavior is the same even if SELINUX=permissive is set

[DemiMarie]

Does this happen if you use the stock Fedora kernel?

[t4777sd]

This was done a fresh fedora 28 template installed via package manager (not fedora 26 + updated to fedora 28) and then it was fully updated via yum update. I made no manual change of the kernel so it would be the default one that would be selected with those steps

@DemiMarie You seem to be wanting DomU hardening, so I assume you are interested in running SELInux. Have you been able to get it to work? If so, any special steps?

[esote]

If you check the console while it's booting (or boot in debug mode), here is the error I get:

[    6.970855] audit: type=1404 audit(1543350043.241:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
SELinux:  Could not open policy file <= /etc/selinux/targeted/policy/policy.31:  No such file or directory
[    6.977989] systemd[1]: Failed to load SELinux policy.
[.[0;1;31m!!!!!!.[0m] Failed to load SELinux policy, freezing.
[    6.979601] systemd[1]: Freezing execution.

So it's missing the SELinux policy.

[marmarek]

Is selinux-policy-targeted package installed?

[esote]

@marmarek No. That fixed that. Now it sits at:

         Starting Relabel all filesystems...

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.

And then it crashes with no more info. Any specific logs I should check besides /var/log/xen/console/guest-vmname.log (which only has above)?

Running fixfiles relabel (disabled SELinux so I could access the VM) results in "No suitable file systems found."

[marmarek]

Try increasing qrexec_timeout property.

[esote]

@marmarek It works!

It took a few minutes, but went through giving progress until complete. It "restarted" the VM once done. This caused an error message to pop up, but I just had to start it again and now SELinux is enabled:

$ sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          error (Success)
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31

[marmarek]

Current mode: permissive

This isn't really protecting anything... What happens if you switch to enforcing mode? Check also if processes are labeled (ps auxZ).

[esote]

@marmarek My bad, not my intention to spam this issue. You're right, enabling enforcing mode does keep it from booting (and blocks different Qubes-related actions if enabled post-boot). Here is the error from that:

[    7.453783] SELinux:  policy capability network_peer_controls=1
[    7.453802] SELinux:  policy capability open_perms=1
[    7.453813] SELinux:  policy capability extended_socket_class=1
[    7.453826] SELinux:  policy capability always_check_network=0
[    7.453839] SELinux:  policy capability cgroup_seclabel=1
[    7.453850] SELinux:  policy capability nnp_nosuid_transition=1
[    7.468025] audit: type=1403 audit(1543369175.969:3): policy loaded auid=4294967295 ses=4294967295
[    7.469698] systemd[1]: Successfully loaded SELinux policy in 424.223ms.
[    7.482404] systemd[1]: Failed to mount tmpfs at /run: Permission denied
[    7.483844] audit: type=1400 audit(1543369175.985:4): avc:  denied  { relabelto } for  pid=1 comm="systemd" name="bpf" dev="sysfs" ino=5011 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:bpf_t:s0 tclass=dir permissive=0
[    7.483874] systemd[1]: Unable to fix SELinux security context of /sys/fs/bpf: Permission denied
[.[0;1;31m!!!!!!.[0m] Failed to mount API filesystems, freezing.
[    7.484324] systemd[1]: Freezing execution.

[ideologysec]

Seems like the SELinux policies need to be written. Have you tried dumping the actions in permissive mode and creating rules, then testing in enforcing?

[DemiMarie]

@ideologysec I have done that, and it works. The one caveat is that one must use dbus-daemon instead of dbus-broker, since the latter is busted when SELinux is involved.

[ritschmaster]

Just dumping my experience on this issue: I made it to actually run SELinux in the enforcing mode. But I am not really into SELinux, I did mess with labeling some Qubes files and tracking them in a module, but failed terrible.

The following steps allowed me running a Fedora based VM named selinuxtest in the enforcing mode:

1. In dom0:
   1. qvm-prefs -s selinuxtest kernel ''
   2. qvm-prefs -s selinuxtest virt_mode hvm
2. In selinuxtest:
   1. sudo dnf install -y selinux-policy* policycoreutils* audit
   2. sudo shutdown -h now
   3. Edit /etc/selinux/config and set SELINUX=permissive
3. In dom0
   1. qvm-prefs -s selinuxtest qrexec_timeout 600
   2. qvm-prefs -s selinuxtest kernelopts "nopat security=selinux selinux=1 enforcing=0 autorelabel=1"
   3. qvm-start selinuxtest
4. In selinuxtest
   1. sudo su root
   2. grep qubes /var/log/audit/audit.log | audit2allow -M qubes
   3. semodule -i qubes.pp
   4. sudo setenforce 1

Sometimes it then works to open another Terminal via qvm-start and sometimes it does not.

[DemiMarie]

I have a git repository (which I will publish soon) that includes working SELinux policies for Fedora. I have SELinux enforcing on most qubes I use, including the one I am using to type this message.

[ideologysec]

@DemiMarie any updates on the repo with working SELinux policies?

[DemiMarie]

@ideologysec My current repo will need significant cleanup, and there have been many other high-priority issues lately.

[DemiMarie]

Questions that still need to be answered:

• [ ] Should Qubes OS include workarounds for upstream bugs?
• [ ] Should user be mapped to staff_u or unconfined_u?
• [ ] How much should upstream-provided interfaces be used?
• [ ] Should the policy use the old policy language, or the Common Intermediate Language?

[DemiMarie]

Not sure what the milestone for this should be.

[andrewdavidwong]

Not sure what the milestone for this should be.

Earliest affected release, which appears to be 4.0, so the current one is correct.

[DemiMarie]

This is now implemented.

[xbc5]

@ideologysec

[ideologysec]

@xbc5 thanks for the ping. And thanks everyone for the hard work of making this happen!

[jvoisin]

Given that there is passwordless sudo with a lengthy justification on how privesc are alright, what is the point of enabling SELinux in Fedora Qubes?

[marmarek]

User is running unconstrained, but having SELinux enabled allows using it for various in-VM sandboxes, like podman, bubblewrap, but also for extra hardening of receiving side of qvm-copy.