Solving Libvirt virtualization issues under grsecurity RBAC

(No. 0)  No. 1 

For some reason, I've been unable to get Libvirt running Virtual Machines, with (sans-dbus) virt-manager's virt-install and virt-viewer, all of the aforesaid under grsecurity RBAC policy enabled.

I'm left with no other option but truly understand as much as I can what is really going on with the network and why I can't connect to internet with the VMs I start.

I've wrestled these issues for some time now, and at the time of starting this page you can read where I reached at this latest post of this topic at grsecurity forums:

Libvirt virtualization policies

This page is actually another attempt on the heels of what I've already posted over under:

Devuan in VM with virt-install with grsec RBAC enabled and then disabled (13)

so you might need some of my explanations I wrote there to understand here (I always try to write in such way that even stubborn and hardworking newbies can follow, although if you really are very new, you will have to either have golden talent, or apply huge work to be able to follow, especially because also some information is scattered in various places --all of them are linked to, I did try to make sure to that).

---

First run is (again) with grsecurity's RBAC policy enabled.

dump_170311_0328_g0n.pcap

---

And the second run is with grsecurity disabled. Which, put together, shows that, at this time, I don't have a grsecurity RBAC policy for Libvirt and associated programs that I can enable and get the Libvirt do its job... As soon as I enable RBAC policy that I prepared so far, Libvirt fails to connect its VMs to internet, while it otherwise has no issues connecting them to internet.

dump_170311_0419_g0n.pcap

---

If some of my usual programs wouldn't run correctly, and you don't have a ~/.sslkey.log of your own, maybe creating an empty file like in this case dump_170311_0328_g0n_SSLKEYLOGFILE.txt and dump_170311_0419_g0n_SSLKEYLOGFILE.txt would help, because there were no SSL keys logged at all.

I'm not sure if the issue lies in RBAC permissions missing for some reason for some functionalities in the layer 2 such as ARP, or in the network layer or is it that some settings in my /etc/grsec/policy somehow disallow some UDP ports or is it something else yet...

But I might have somewhat easier task getting the missing touch to my grsecurity policy if I try and compare what these commands get me:

tshark -r dump_170311_0328_g0n.pcap -Y \
	'((arp) || (udp.port eq 67 and udp.port eq 68)) \
	&& !(ip.addr==10.16.96.1)' \
	-w dump_170311_0328_g0n_arp_udp_notJuniper.pcap

and:

tshark -r dump_170311_0419_g0n.pcap -Y \
	'((arp) || (udp.port eq 67 and udp.port eq 68)) \
	&& (ip.addr!=10.16.96.1)' \
	-w dump_170311_0419_g0n_arp_udp_notJuniper.pcap

with the syslog messages messages_170311_0328_g0n and messages_170311_0419_g0n respectively, where the exec_logging and audit_chdir functionality of grsecurity give ample info about those exact events in the now very much reduced network traces...

I'll create a separate page to analyze this further.

Current attempt before I got lost-tired in preparing the script is at:

No. 1  (but that page may be replaced with better presentation, if I manage to put the uncenz-2nd of my uncenz set of scripts together, which I am trying to do, but, don't know, maybe I wouldn't bet on my success myself...)

---

The files necessary for this study are listed in:

ls-1

dump_170311_0328_g0n.pcap
dump_170311_0328_g0n_arp_udp_notJuniper.pcap
messages_170311_0328_g0n
Screen_170311_0328_g0n.webm
dump_170311_0419_g0n.pcap
dump_170311_0419_g0n_arp_udp_notJuniper.pcap
messages_170311_0419_g0n
Screen_170311_0419_g0n.webm

and verify to: ls-1.sum signed by: ls-1.sum.asc

You might find dump_dLo.sh script from my uncenz program more useful then downloading each file separately.