On Thu, Sep 16, 2010 at 08:31:45AM -0400, Ayal Baron wrote: > > ----- "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > > > On Tue, Sep 14, 2010 at 05:03:21PM -0400, Ayal Baron wrote: > > > > > > ----- "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > > > > > > > > > > > That is probably possible with the current security driver > > > > implementations > > > > but more generally I think it will still hit some trouble. > > > > Specifically > > > > one of the items on our todo list is a new security driver that > > makes > > > > use > > > > of Linux container namespace functionality to isolate the VMs, so > > they > > > > > > > > can't even see other resources / processes on the host. This may > > well > > > > prevent the sync manager wrapper talking to a central sync mnager > > > > process > > > > The general rule we aim for is that once libvirtd has spawned a > > VM > > > > they > > > > are completely isolated with exception of any disks marked with > > > > <shareable/> > > > > In other words, any communictions channels must be > > > > initiated/established > > > > by the mgmt layer to the VM process, with nothing to be > > established in > > > > the > > > > reverse direction. > > > Correct me if I'm wrong, but the security limitations (selinux > > context) > > > would only take effect after the "exec", no? so the process could > > still > > > communicate with the daemon, open an FD and then exec. After exec, > > the > > > VM would be locked down but the daemon could still wait on the FD to > > see > > > whether VM has died. > > > > It depends on which exec you are talking about here. If the comms to > > the daemon are done straight from the libvirtd plugin, then it would > > still be unrestricted. If the comms were done from the supervisor > > process, it would be restricted. > > > > Daniel > I'm talking about the supervisor. You said you spoke to Dan Walsh and > that the supervisor and qemu processes could get different contexts. > Now you're saying the supervisor would be restricted nonetheless. What > am I missing? The distinction is between what is possible, and what is recommended to do. Even with the supervisor & QEMU having separate SELinux contexts, it is still desirable to lock down the supervisor to only be able to access the VM lease file & only its own QEMU pid. So while we could write policy such that a supervisor can talk to a central lock daemon, it is preferrable for the lock supervisor to be self contained. The other point I make is that SElinux is the main security driver today, but others will come along in the future. A container based security driver will almost certainly completely isolate the spawned processes with no option to talk to a central lock daemon. There would be separate filesystem namespace, PID namespace, network namespace per VM - in essence each process would see its own isolated OS with only QEMU & the optional lock supervisor running in it. So to get a maximally flexible & future proof sync maanger plugin, it is best to any reliance on a central daemon, even if that is technically possible today. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list