latest F19 policy update killed qemu ?

[Dmitry Makovey]

Hi everybody,

today, right after update my machine refuses to start any of the VMs it 
was happily running just a minute ago.

Some details:

$ rpm -qa | grep selinux-policy
selinux-policy-targeted-3.12.1-74.15.fc19.noarch
selinux-policy-devel-3.12.1-74.15.fc19.noarch
selinux-policy-3.12.1-74.15.fc19.noarch

# grep qemu-system-x86 /var/log/audit/audit.log | audit2allow

#============= svirt_t ==============
allow svirt_t virt_image_t:file read;

# ls -laZ /var/lib/libvirt/images/
drwx--x--x. qemu qemu system_u:object_r:virt_image_t:s0 .
drwxr-xr-x. root root system_u:object_r:virt_var_lib_t:s0 ..
-rw-r--r--. qemu qemu system_u:object_r:virt_image_t:s0 devstack-f.qcow2
...

in other words - I see no reason why this should fail, what did I miss?

Should I head over to bugzilla and report?

[Dmitry Makovey]

On 12/16/2013 06:17 PM, Dmitry S. Makovey wrote:
> Hi everybody,
>
> today, right after update my machine refuses to start any of the VMs it
> was happily running just a minute ago.
>
> Some details:
>
> $ rpm -qa | grep selinux-policy
> selinux-policy-targeted-3.12.1-74.15.fc19.noarch
> selinux-policy-devel-3.12.1-74.15.fc19.noarch
> selinux-policy-3.12.1-74.15.fc19.noarch
>
> # grep qemu-system-x86 /var/log/audit/audit.log | audit2allow
>
> #============= svirt_t ==============
> allow svirt_t virt_image_t:file read;
>
> # ls -laZ /var/lib/libvirt/images/
> drwx--x--x. qemu qemu system_u:object_r:virt_image_t:s0 .
> drwxr-xr-x. root root system_u:object_r:virt_var_lib_t:s0 ..
> -rw-r--r--. qemu qemu system_u:object_r:virt_image_t:s0 devstack-f.qcow2
> ...
>
> in other words - I see no reason why this should fail, what did I miss?
>
> Should I head over to bugzilla and report?

after some tinkering I've applied svirt_image_t to 
/var/lib/libvirt/images and everything is functioning, however 
"restorecon -RF /var/lib/libvirt/images" brings everything back to 
virt_image_t , hmm?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2013 08:37 PM, Dmitry S. Makovey wrote:
> On 12/16/2013 06:17 PM, Dmitry S. Makovey wrote:
> > Hi everybody,
> >
> > today, right after update my machine refuses to start any of the VMs it 
> > was happily running just a minute ago.
> >
> > Some details:
> >
> > $ rpm -qa | grep selinux-policy 
> > selinux-policy-targeted-3.12.1-74.15.fc19.noarch 
> > selinux-policy-devel-3.12.1-74.15.fc19.noarch 
> > selinux-policy-3.12.1-74.15.fc19.noarch
> >
> > # grep qemu-system-x86 /var/log/audit/audit.log | audit2allow
> >
> > #============= svirt_t ============== allow svirt_t virt_image_t:file
> > read;
> >
> > # ls -laZ /var/lib/libvirt/images/ drwx--x--x. qemu qemu
> > system_u:object_r:virt_image_t:s0 . drwxr-xr-x. root root
> > system_u:object_r:virt_var_lib_t:s0 .. -rw-r--r--. qemu qemu
> > system_u:object_r:virt_image_t:s0 devstack-f.qcow2 ...
> >
> > in other words - I see no reason why this should fail, what did I miss?
> >
> > Should I head over to bugzilla and report?
>
> after some tinkering I've applied svirt_image_t to /var/lib/libvirt/images
> and everything is functioning, however "restorecon -RF
> /var/lib/libvirt/images" brings everything back to virt_image_t , hmm?

libvirt is supposed to change the label of a virt_image_t to
svirt_image_t:MCSLABEL  when the virtual machine is running, and then change
it back to virt_image_t when the VM is finished.  Running VMs can only
read/write svirt_image_t.  The problem is you should not be running restorecon
on this directory.

svirt_image_t is supposed to be in a type that restorecon will not change.

If you stop and restart the VM everything should be labeled correctly.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKwZswACgkQrlYvE4MpobOZNwCeN7ZA2MD69X0J7Ml12FxFRo+i
> VRkAnAzhHEbbAmmECwNOcQ1e9KoHonQD
> =TXnI
> -----END PGP SIGNATURE-----

[Dmitry Makovey]

On 12/17/2013 07:59 AM, Daniel J Walsh wrote:
> > after some tinkering I've applied svirt_image_t to /var/lib/libvirt/images
> > and everything is functioning, however "restorecon -RF
> > /var/lib/libvirt/images" brings everything back to virt_image_t , hmm?
>
> libvirt is supposed to change the label of a virt_image_t to
> svirt_image_t:MCSLABEL  when the virtual machine is running, and then change
> it back to virt_image_t when the VM is finished.  Running VMs can only
> read/write svirt_image_t.  The problem is you should not be running restorecon
> on this directory.
>
> svirt_image_t is supposed to be in a type that restorecon will not change.
>
> If you stop and restart the VM everything should be labeled correctly.

Thanks for the explanation Daniel, now it makes sence why it's refusing 
to startup those vm's - I'm using qcow2 external snapshots :

$ qemu-img create -f qcow2 -b foo.qcow2 foo-snap.qcow2

and apparently that is causing issues as either libvirt is not 
relabeling things properly or something else is wrong but at the start 
time VM has no access to base image[s] (sometimes I daisy-chain 
snapshots up to 3 levels). However the fact is - it stopped working 
yesterday, and this box was always in enforcing mode and functioning 
properly. I did not notice any updates to virtualization layer, however 
there was selinux-policy* version bump, thus I'm here.

At the moment I had to switch to the Permissive since only with "wrong" 
labels I can start VMs.

I will change labels back to virt_image_t in the meantime...

Should I be filing a bug or is there something else that could be done 
to eliminate the issue?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/17/2013 04:28 PM, Dmitry S. Makovey wrote:
> On 12/17/2013 07:59 AM, Daniel J Walsh wrote:
> > > after some tinkering I've applied svirt_image_t to
> > > /var/lib/libvirt/images and everything is functioning, however
> > > "restorecon -RF /var/lib/libvirt/images" brings everything back to
> > > virt_image_t , hmm?
> >
> > libvirt is supposed to change the label of a virt_image_t to 
> > svirt_image_t:MCSLABEL  when the virtual machine is running, and then
> > change it back to virt_image_t when the VM is finished.  Running VMs can
> > only read/write svirt_image_t.  The problem is you should not be running
> > restorecon on this directory.
> >
> > svirt_image_t is supposed to be in a type that restorecon will not
> > change.
> >
> > If you stop and restart the VM everything should be labeled correctly.
>
> Thanks for the explanation Daniel, now it makes sence why it's refusing to 
> startup those vm's - I'm using qcow2 external snapshots :
>
> $ qemu-img create -f qcow2 -b foo.qcow2 foo-snap.qcow2
>
> and apparently that is causing issues as either libvirt is not relabeling
> things properly or something else is wrong but at the start time VM has no
> access to base image[s] (sometimes I daisy-chain snapshots up to 3 levels).
> However the fact is - it stopped working yesterday, and this box was always
> in enforcing mode and functioning properly. I did not notice any updates to
> virtualization layer, however there was selinux-policy* version bump, thus
> I'm here.
>
> At the moment I had to switch to the Permissive since only with "wrong"
> labels I can start VMs.
>
> I will change labels back to virt_image_t in the meantime...
>
> Should I be filing a bug or is there something else that could be done to 
> eliminate the issue?

Yes file a bug on libvirt and we can look at it there.  CC me on the bug.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKwwkcACgkQrlYvE4MpobPMgQCfYHDlPuqkTMJFC2pnMuWb8S50
> M+kAoJ1cWGTZANeUdLyJFeFWICM9RLxY
> =h7LR
> -----END PGP SIGNATURE-----

[Dmitry Makovey]

On 12/17/2013 02:29 PM, Daniel J Walsh wrote:
> > Should I be filing a bug or is there something else that could be done to
> > eliminate the issue?
>
> Yes file a bug on libvirt and we can look at it there.  CC me on the bug.

done: https://bugzilla.redhat.com/show_bug.cgi?id=1044217

ran some extra tests too: it is indeed the change in system behaviour 
and not local changes on the box (bug explains a bit on that).