On Thu, Nov 24, 2011 at 09:11:20AM +0000, Daniel P. Berrange wrote:
> 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.
For clarity here are some examples of why you can't do checks at the API
level, and instead must do it inside each driver
* The virDomainDefineXML API - you need todo two separate checks, one
if the config does not already exist (eg defining a new guest), and
another if the config does exist (updating an existing guest).
* virDomainListDomains API - you need to filter the returned list of
IDs to only those the user is allowed to view. You can't do the filtering
if you only have the IDs, so it needs to be done inthe driver
* virDomainListDomains, virDomainNumOfDomains, virDomainListDefinedDomains,
virDomainNumOfDefinedDomains - these will all collapse to a single
"list" operation, filtering for the user
* All APIs - with SELinux you need the context from the domain XML
which is not available at the API level.
* virDomainCreateXML API - as with DefineXML there are two separate
checks required - one if a config does not exist (starting an brand
new transient guest) vs one if a config does exist (starting a
persistent guest, with a temporarily different config).
* virDomainAttachDevice API - need to todo different checks for the
different types of device being attached & potentially multiple
checks if the attached device references other host resources.
eg a PCI device attach with managed=yes, must check that the user
is allowed to attach a device, and also check that the user is
allowed to detach & reset host PCI devices.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|