[libvirt] RFC [3/3]: Lock manager usage scenarios

[Daniel P. Berrange]

On Tue, Sep 14, 2010 at 05:03:21PM -0400, Ayal Baron wrote:
> 
> ----- "Daniel P. Berrange" <berrange at redhat.com> 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
-- 
|: 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 :|