Mailing List Archive: OpenStack: Dev

[OSSA 2012-011] Compute node filesystem injection/corruption (CVE-2012-3447)

1 2

View All

Index | Next | Previous | View Threaded

eric at cloudscaling

Aug 14, 2012, 1:51 PM

Post #26 of 27 (57 views)
Permalink

Re: [OSSA 2012-011] Compute node filesystem injection/corruption (CVE-2012-3447) [In reply to]

On Tuesday, August 14, 2012 at 16:41 PM, Matt Joyce wrote:

> I get what you are saying. And for the sake of compatibility with other clouds and their images obviously that's the way to go, but my inner nerd is screaming "Well, about that... " and wanting me to rally people to the idea of putting the logic inside the images rather than inside of the cloud. Let init negotiate the api access and produce the filesystems it needs to get booted up properly.
>
Are we having the same conversation? :-) You were arguing for FUSE, I simply said that particular user-space solution isn't very viable due. Otherwise, I believe you and I agree.

I agree that the the approach being taken here isn't ideal. However, I also advocate that if this path is going to be traveled, it should be done in the safest way possible - in userspace, and write-once-read-never, if at all possible. However, I'm not too confident of libguestfs, but I understand why it is attractive in absence of good userspace filesystem tools. Several have pointed to mtools as one, and I'll also add debug2fs to this list, for those of strong conviction.

Regards,
Eric Windisch

rich at annexia

Aug 14, 2012, 2:03 PM

Post #27 of 27 (54 views)
Permalink

Re: [OSSA 2012-011] Compute node filesystem injection/corruption (CVE-2012-3447) [In reply to]

On Tue, Aug 14, 2012 at 11:30:29AM -0700, Matt Joyce wrote:
> I have to ask. Wasn't FUSE designed to do alot of this stuff? It is
> userspace and it doesn't do nasty stuff to file systems. Why aren't we
> going that route?

FUSE is not really related to this issue. It's just the API.

You can use libguestfs over FUSE. Indeed that's how OpenStack works
right now, albeit using the external 'guestmount' program, whereas
with libguestfs >= 1.18 you'll be able to use the much cleaner
'mount-local' core API.

http://libguestfs.org/guestmount.1.html
http://libguestfs.org/guestfs.3.html#mount-local

The issue is what thing, underneath the API, is actually accessing the
filesystem. If you're mounting stuff directly on the host, then that
thing is the host kernel, which is really the worst scenario from a
security p.o.v.

If (as some have suggested) you're using a userspace program on the
host, then you've got a userspace program which can be exploited that
then has direct access to the host.

With libguestfs, accessed either via the libguestfs native API or over
FUSE, you've got the regular qemu/KVM process buffering you from any
exploits. In essence, this is the same situation as when you're
running any VM, so it's just as safe (or unsafe) as Nova is already.

http://libguestfs.org/guestfs.3.html#architecture
http://libguestfs.org/guestfs.3.html#api-overview
http://libguestfs.org/guestfs.3.html#security

With libguestfs *and* libvirt (in libguestfs >= 1.19.25), you've got
not just the qemu wrapper, but also SELinux controlling exactly what
the qemu process can see and do in the host, ie. sVirt.

http://selinuxproject.org/page/SVirt
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-sVirt.html

Rich.

--
Richard Jones
Red Hat

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads