On 04/26/2013 11:42 AM, Daniel P. Berrange wrote:
On 04/26/2013 04:52 AM, Daniel P. Berrange wrote:
On Thu, Apr 25, 2013 at 09:44:33PM -0400, Laine Stump wrote:
We don't know exactly the names of the VFIO devices that will be needed (and due to hotplug, we can't ever assume we won't need them at all), so we just add an ACL to allow any vfio device - they all have the major number 244 (/dev/vfio/vfio is 244,0, and the /dev/vfio/n devices are up from there). We do the correct labelling of the /dev/vfio/"N" device in the security drivers, so we should be able todo the same for cgroups device ACL. Allowing all "N" is not acceptable from a security POV. Up until now there hasn't been any cgroup-related code in the security drivers, though. So where should this go? Do we need a new driver backend for cgroups? This would then mean that we need to have three tiers of security drivers rather than two. Or can it just be put in the DAC driver? We manage perfectly well to configure ACLs for individual disks that a VM is given without having to wildcard allow every single /dev/sdN disk. That fact that you were able to make the security drivers label
On Fri, Apr 26, 2013 at 11:16:14AM -0400, Laine Stump wrote: the /dev/vfio/n devices correctly, shows that the information required is available. So why can't you set the cgroups ACLs correctly here too ? There's no need to move cgroups code into any security driver.
Sorry, my brain combined the first and second sentences of your message, and understood that you wanted this to happen in the security driver. I'll look up what's done for disks.