It was reported that the libvirt daemon using RBD leaks ceph key/id in the process list: As a non-privileged user you can run `ps -ef | grep libvirt` and see the below output. In this you can see libvirt using the ceph key as part of the command to run the VM. In particular this section ~~~ -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:auth_supported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback ~~~ With the 'id' and 'key' values, any user can perform any operations on the cluster which that key provides. Typically, that would be the ability to create/delete RBDs within the cinder pool. Full output: ~~~ qemu 13924 1 33 Dec10 ? 2-23:31:12 /usr/libexec/qemu-kvm -S -M rhel6.1.0 -enable-kvm -m 8000 -smp 8,sockets=8,cores=1,threads=1 -name os-network -uuid f0ede7e8-c15a-4813-900e-971988d494c1 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/os-network.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:auth_supported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:64:92:b6,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:f7:50:e2,bus=pci.0,addr=0x4 -netdev tap,fd=30,id=hostnet2,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=52:54:00:14:3b:33,bus=pci.0,addr=0x5 -netdev tap,fd=32,id=hostnet3,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=52:54:00:fd:86:aa,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:5 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x8 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 ~~~
Why is this bug embargoed? It has been public knowledge since 2011 that passing Ceph keys on the command line is undesirable: https://www.redhat.com/archives/libvir-list/2011-November/msg00853.html and we're STILL waiting on qemu to give us a file-descriptor backdoor for RBD disks that will allow us to pass auth without using the command line.
Corrected CVSS2 scoring (this only affects confidentiality).
FYI, I am doing some work on QEMU which should allow us to address this problem. Will post a link to patches when there's something to show.
The QEMU side of the fix for this problem is queued for the QEMU 2.6 release: https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg01624.html Work can now begin on the libvirt side of the fix
Here's a run through of what I think we should do in libvirt to fix this. - Every libvirt KVM guest that is started should be given a master secret in /var/lib/libvirt/qemu/$GUEST-master.key This should be provided to QEMU at startup using -object secret,id=master0,file=/var/lib/libvirt/qemu/$GUEST-master.key,format=base64 - When we need to pass secrets to QEMU for network disk passwords, or for decryption passphrases, or for TLS certificate passwords, we should encrypt the secret with the master key, and pass the encrypted secret data inline using "-object secret,id=sec0,data=[base64 ciphertext],keyid=master0,iv=[base64 IV],format=base64" This ensures that we don't need to mess around with file descriptor passing or creating/deleting temporary files to hold the secret for hotplugging disks. It is also nice because users can still cut + paste the command line args from /var/log/libvirt/qemu/$GUEST.log and have things "just work" even with secrets in use.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:2577 https://rhn.redhat.com/errata/RHSA-2016-2577.html
Statement: Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates of Enterprise Linux 6. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.