|
From: | Corey Bryant |
Subject: | Re: [Qemu-devel] virtio-rng and fd passing |
Date: | Mon, 04 Mar 2013 10:55:10 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 |
On 03/04/2013 05:29 AM, Daniel P. Berrange wrote:
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote:I understand the reason that fdsets exist (because NFS is stupid and doesn't support labeling). But we aren't doing dynamic labeling of /dev/random and I strongly suspect it's not on NFS anyway. So why are we trying to pass fds here?Consistency - how do you write a policy that allows open("/dev/random") while forbidding open("/nfs/...")? It's much simpler to forbid open(), even if /dev/random doesn't have any labeling issues.IIUC, it is actually pretty straightforward from a policy POV. Every filesystem has a unique type, and SELinux can make rules scoped to that filesystem type. That's how we have the 'virt_use_nfs' tunable already which only affects NFS. Daniel
Yes it should be simple, at least for SELinux. I think all we need to do is remove open permission from the qemu process (svirt_t) on NFS files (files labeled with nfs_t).
Here's what I see for base qemu permissions on NFS files on Fedora 18: $ sesearch -A -s svirt_t -t nfs_t | grep ": file" | grep openallow virt_domain nfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
And I think 'setsebool -P virt_use_nfs 0' will remove the open permission, so this may already be covered.
I'm not sure how easy it is for other MAC implementations. Last I checked AppArmor didn't have the granularity of preventing open and allowing read/write.
-- Regards, Corey Bryant
[Prev in Thread] | Current Thread | [Next in Thread] |