[libvirt] [RFC PATCHv4 14/15] qemu: skip granting access during fd migration

[Eric Blake]

On 03/10/2011 05:19 AM, Daniel P. Berrange wrote:
> On Wed, Mar 09, 2011 at 07:18:32PM -0700, Eric Blake wrote:
>> SELinux labeling and cgroup ACLs aren't required if we hand a
>> pre-opened fd to qemu.  All the more reason to love fd: migration.
> 
> I know that holds true for cgroups which checks on open() only,
> but are you absolutely sure about for SELinux? SELinux checks
> FDs on every single syscall. I'm really fuzzy about what happens
> to an FD's associated security context when you pass it over
> an UNIX socket using SCM_RIGHTS. I think it might 'just work'
> as we already do this with TAP devices and don't label them,
> but it could be we have a generic policy rule related to TAP
> devices.

Whether surprising or not, it worked without doing any labeling on the
fd.  I don't know if that's a hole in SELinux.

In fact, it's more than just the SELinux labeling - it's also the DAC
labeling (that is, pre-patch, the file is owned by qemu:qemu during the
migration, then chown'd back to root:root on completion; post-patch, the
file is never chown'd in the first place, and it is the SCM_RIGHTS of
the open fd that lets a non-root process write into a 600 root:root
file).  But that's not a hole (it's always been possible in Unix to do
things on open fds where you can't do the same by attempting open()
yourself on the same underlying file - for example,
open(file,O_CREAT|O_RDWR,0000) lets you read and write into a temporary
fd that not even another process with the same uid can reopen.  Or put
another way, an open fd is stateful - it remembers the permissions at
the time of the open, and not is not impacted by any intervening chmod
or chown of the underyling file).

> 
> If it passed testing with SELinux in enforcing mode, then ACK

It does indeed pass (to my relief).

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110325/b0e91003/attachment-0001.sig>