Description of problem: Permissions of VM disk files are too wide. Any user is able to read the instance disk and can extract any secret from it. Version-Release number of selected component (if applicable): Customer environment is with OSP version : 16.2 How reproducible: Every time. Steps to Reproduce: 1. 2. 3. Actual results: Permissions look like below at present. ls -l /var/lib/nova/instances/ef076d9a-2408-4d3c-97d9-8fe815f98785/ total 115204 -rw-------. 1 root root 18527 Aug 19 12:02 console.log -rw-r--r--. 1 qemu qemu 116785152 Aug 23 13:16 disk -rw-r--r--. 1 qemu qemu 493568 Aug 19 12:02 disk.config -rw-r--r--. 1 42436 42436 79 Aug 19 12:01 disk.info Expected results: Expectation is that these files should not have read permission for others. Additional info:
Hi, I don't see a security concern here. Nova relies on libvirt's "sVirt" (SELinux-based security mechanism), to isolate each guest from the other guest by giving each guest (a QEMU process) and its associated disk image a unique label. - - - Here's how it works: (1) Start two guests ('rhel-8' and a 'cirros-0.3.5') on a server. And check the SELinux context of the two running QEMU processes (the only two on this host). Notice the SELinux's MCS label (an SELinux mechanism that allows an admin to label files with "categories") for each QEMU process are different: "c115,c830" and "c290,c684": $> ps -eZ | grep qemu-kvm system_u:system_r:svirt_t:s0:c115,c830 2330 ? 00:00:15 qemu-kvm system_u:system_r:svirt_tcg_t:s0:c290,c684 3949 ? 00:00:02 qemu-kvm (2) Now check the SELinux context of the two disks, that are associated with their respective QEMU processes (from the previous step): $> ls -lZ /export/vms/rhel-8.qcow2 /export/vms/cirros-0.3.5.qcow2 -rw-rw-r--. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c115,c830 1298268160 Nov 30 18:34 /export/vms/rhel-8.qcow2 -rw-r--r--. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c290,c684 16121856 Nov 30 18:34 /export/vms/cirros-0.3.5.qcow2 If you squint, you'll notice that each disk's SELinux "MCS label" from step (2) matches its QEMU process from step (1): - "c115,c830" -- for 'rhel-8.qcow2' & its QEMU process - "c290,c684" -- for 'cirros-0.3.5.qcow2' & its QEMU process Therefore, if the CirrOS process is compromised, it is isolated to _that_ particular process. I hope that answers your concern. If you have more specific concerns, please elaborate.
This can't be both 17.1 and 18 - since 17.1 was set during Triage, I'm going to take 17.1 as the correct one.
The umask controlled behavior got a pushback as it regressed libvirt for NFV scenatrios, see https://bugzilla.redhat.com/show_bug.cgi?id=2166979#c27 and https://bugzilla.redhat.com/show_bug.cgi?id=2167102#c16. Reverting changes back and returning this back to the roadmap for better analysis to be done by libvirt SMEs.
Closing as CantFix as the reverts have now merged upstream and downstream and it has been added to our future feature backlog to be addressed upstream in nova.