• 1
Hi Dan,

I'm not sure I understand this - why a virtual machine running as svirt_t:s0:c1,c2 not be able to write to a file labeled svirt_tmp_t:s0:c1? And is the requirement to stop the files being labeled s0 simply to prevent all svirt_t processes being able to write to them?


Your correct a svirt_t:s0:c1,c2 would be able to read a svirt_tmp_t:s0:c1 file, which is why libvirt/sandbox/openshift ... are coded not to do that.

These applications all label with two unique categories, to avoid this problem.

Eventually we might need to go to three categories for systems like OpenShift if they grow to large. Especially if we go with a Unigue UID for a gear across all Nodes.

Yes libvirt's goal is to pick an Unique MCS Label for svirt_t (the process) and svirt_image_t (the image label).

When it gets a unique one, it assigns it to all of that virtual machines content, then launches the process.

It always picks a 2 UNIQUE category MCS label, and there for no two labels are able to write to each others labels.

When libvirt stops a virtual machine, it relabels all of the content back to a TYPE label which no virtual machines can read or write.

For example say you had a virtual machine with an image file


When the virtual machine is running as svirt_t:s0:c1,c2 this image will be labeled svirt_image_t:s0:c1,c2 When the VM is stopped libvirt will relabel the image to virt_image_t:s0.

Type enforcement prevents any svirt_t from reading or writing virt_image_t.

relabelto with mcs constraint

Hello Dan,

Is there a way I can restrict 'relabelto' to only select mcs category


libvirtd running as "system_u:system_r:virtd_t:SystemLow-s0:c0.c128" should only be allowed to relabelto "system_u:system_r:virtd_t:s0:c127" and relabelling "system_u:system_r:virtd_t:s0:c129" outside its category should fail

Is this something doable??

Re: relabelto with mcs constraint

No. MCS does not have this level of flexibility.

You need to change types if you want to add different access.

  • 1

Log in