On 04/26/2013 11:42 AM, Daniel P. Berrange wrote:
On Fri, Apr 26, 2013 at 11:16:14AM -0400, Laine Stump 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
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.