Re: [libvirt] ACLs for libvirt

On Wed, Nov 23, 2011 at 06:17:46PM +0100, Michal Privoznik wrote: > Hi all, > > I'd like to implement this new feature for libvirt. However, I think we > should settle down on design first. My biggest concern is choosing the > right level on on which ACLs will be implemented. Should be interested > only in (user, API), or with more granularity (user, API, API's parameters)? > Or should we take the RBAC path? > How should we even identify and authorize users? > > My initial though is to create framework which can be used then to > implement ACLs on any level we want. > > What's our opinion? I have been working on the plan & investigating various implementation details of this myself over the past few months. Here is the initial design mail I had on the subject: https://www.redhat.com/archives/libvir-list/2011-June/msg00244.html In terms of level of ACLs, this isn't something that can be done at the "API" entry point level, since it is only secure to perform checks after the internal object has been obtained by the driver: eg, consider a virDomainPtr instance containing name=foo, uuid=c7b3edbd-edaf-9455-926a-d65c16db1800 Now, the QMEU driver does virDomainObjPtr vm = virDomainObjLookupByUUID(c7b3edbd-edaf-9455-926a-d65c16db1800) And could in theory get back a virDomainObjPtr instance containing name=bar, uuid=c7b3edbd-edaf-9455-926a-d65c16db1800 If our access control checks specify "allow { name=foo }", then we should *deny* access, because the actual object we're about to use has name=bar. If we did the checks at the API entry point level, we would mistakenly allow access. In addition "API" is really the wrong level of granularity for expressing the checks. Several separate APIs will need to be covered under the same check, while at the same time, one API might require multiple checks.