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

[Daniel P. Berrange]

On Thu, Sep 16, 2010 at 08:31:45AM -0400, Ayal Baron wrote:
> 
> ----- "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
> > 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
> 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 :|