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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list