On Thu, Nov 24, 2011 at 09:45:44AM +0000, Daniel P. Berrange wrote:
> On Thu, Nov 24, 2011 at 09:11:20AM +0000, Daniel P. Berrange wrote:
[...]
> > 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.
So basically you say we can't check at the API level here because
we can't trust the virDomainPtr and can only base the checks on the
API internal data structures like virDomainObjPtr. I tend to agree
then, and that means that the check is to be done in the final driver
as a result (e.g. the qemu one, not at the remote level).
> > 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).
Okay
> * 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
Here I'm far less convinced. To me the role system influence the API
in saying if you can run the API or not. In that case you want to change
the API output. I'm not sure it's a good idea. If I take the unix
analogy, it's okay to forbid listing directories (even if some files
may be accessible to the user), but changing the directory listing
based on whom does the operation makes an awful lot of things more
complex. I'm not sure we want to do this !
> * virDomainListDomains, virDomainNumOfDomains, virDomainListDefinedDomains,
> virDomainNumOfDefinedDomains - these will all collapse to a single
> "list" operation, filtering for the user
I'm not sure I agree on changing the API semantic.
> * All APIs - with SELinux you need the context from the domain XML
> which is not available at the API level.
okay
> * 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).
okay all create operations are overloaded by allowing override.
> * 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.
If we try to go too fine grained we are likely to make it too hard
to use, I see a risk here.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list