On 04/26/2010 08:31 AM, Daniel P. Berrange wrote:
What you describe is not inherant to the daemon model. This is why we
have
two separate models in libvirt. The system instance is pre-spawned with
high privileges, to allow use of hosts resources which require high
privileges to access. The session instance is auto-spawned when the app
connects to libvirt, thus it inherits the privileges of the app that is
using it.
I don't deny that the system instance has a new attack surface, because it
is running privileged. If the app needs to connect VMs to privileged
resources, then the architecture has to have some privileged component
to give access to those resoruces. You don't want the VM to be privileged,
nor the whole management app to be privileged. The system daemon is thus the
arbitrator for this privileged access. If you don't need todo anything that
requires higher privileges though, just use the session instance which
always matches the apps privileges.
I regret saying "more secure" because I think it's a difficult concept
to really quantify and that makes it hard to meaningfully discuss.
The reason I lean toward the direct launch model is that it gives the
user a lot of flexibility in terms of using things like namespaces, DAC,
cgroups, capabilities, etc. A lot of potential features are lost when
you do indirect launch because you have to teach the daemon how to
support each of these features.
Regards,
Anthony Liguori
Daniel