OpenStack Compute (Nova)

image files in _base should not be world-readable

Reported by David Ripton on 2013-02-19
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Medium
Unassigned

Bug Description

Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide.

We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data.

CVE References

David Ripton (dripton) wrote :

Er, that should have been https://bugzilla.redhat.com/show_bug.cgi?id=893100 Sorry for the mixup.

Thierry Carrez (ttx) wrote :

Yeah, that should be fixed, but not worth an advisory (as it relies on another vulnerability to be exploited). Can be fixed publicly.

tags: added: security
Changed in nova:
importance: Undecided → Medium
status: New → Confirmed
information type: Private Security → Public
Changed in nova:
assignee: nobody → David Ripton (dripton)
status: Confirmed → In Progress
Matthew Thode (prometheanfire) wrote :

Any update on this, is it on hold til Havana?

David Ripton (dripton) wrote :

devstack-gate isn't letting this fix in. It's probably a devstack problem, as the patch is very simple, but until I figure it out, it can't go in. If I can get it passing in the next few days, I'd still like to get it into Grizzly. If not, it'll have to slip to Havana.

Changed in nova:
milestone: none → havana-1
Matthew Thode (prometheanfire) wrote :

What is the status on this?

David Ripton (dripton) wrote :

I'm still working on it, intermittently. The devstack exercise.sh tests fail to start an instance with my patch in, for an unknown reason.

Thierry Carrez (ttx) on 2013-05-29
Changed in nova:
milestone: havana-1 → havana-2
Xavier Queralt (xqueralt) wrote :

I don't see a clear solution for this problem in nova and I think this could be better handled in the packaging.

When changing the mode of the instances' directory to 0760 we are also preventing the user 'qemu' to access the images and other files we store there (See nova-compute logs @ 2013-06-07 15:35:00.955 [1]).

From libvirt's documentation [2]:

"The directories /var/run/libvirt/qemu/, /var/lib/libvirt/qemu/ and /var/cache/libvirt/qemu/ must all have their ownership set to match the user / group ID that QEMU guests will be run as. If the vendor has set a non-root user/group for the QEMU driver at build time, the permissions should be set automatically at install time. If a host administrator customizes user/group in /etc/libvirt/qemu.conf, they will need to manually set the ownership on these directories."

In Fedora and RedHat the QEMU guests run as qemu (group qemu) while in debian and ubuntu they runs as libvirt-qemu (group kvm).

An easy solution would be to just change the group of the instances directory to the one qemu is going to use (either qemu or kvm) while still changing the permissions on that directory to 0760. And I'd definitely do this on the packaging level.

Because, besides libvirt, is there any other virt driver storing images in the instances directory?

[1] http://logs.openstack.org/32146/2/check/gate-tempest-devstack-vm-full/21468/logs/screen-n-cpu.txt.gz
[2] http://libvirt.org/drvqemu.html#securitydriver

David Ripton (dripton) wrote :

Thanks Xavier. My patch failed because it narrowed permissions to only the openstack user, not also the qemu user.

I agree that group permissions should fix this. But I think it's safer to do it internally in nova rather than punting to packagers, if we can. That way we fix it once rather than relying on others to fix it multiple times. The challenge is knowing the correct group in a portable way.

Changed in nova:
milestone: havana-2 → havana-3
Changed in nova:
assignee: David Ripton (dripton) → Xavier Queralt (xqueralt)
Thierry Carrez (ttx) on 2013-09-05
Changed in nova:
milestone: havana-3 → havana-rc1
Matthew Thode (prometheanfire) wrote :

This planned for backport to 2012.2 and/or 2013.1?

Thierry Carrez (ttx) wrote :

No, but depending on the final shape of the fix it might be possible...

Changed in nova:
milestone: havana-rc1 → none
tags: added: havana-rc-potential libvirt
Thierry Carrez (ttx) on 2013-10-14
tags: added: havana-backport-potential
removed: havana-rc-potential
Changed in nova:
assignee: Xavier Queralt (xqueralt) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.