On Tue, Nov 29, 2011 at 11:18:42AM -0600, Adam Litke wrote:
> On Tue, Nov 29, 2011 at 04:50:19PM +0000, Daniel P. Berrange wrote:
> > On Tue, Nov 29, 2011 at 10:29:41AM -0600, Adam Litke wrote:
> > > After discussing MOM / VDSM integration at length, two different 
> > > strategies have
> > > emerged.  I will call them Plan A and Plan B:
> > > 
> > > Plan A: MOM integration at the OS/Packaging level
> > > Plan B: MOM integration as a new VDSM thread
> > > 
> > > This RFC is about Plan A.  I will start another thread to discuss Plan B 
> > > once I
> > > have properly prototyped the idea in code.
> > > 
> > > Integration VDSM and MOM at the OS level is by far the simpler and least
> > > intrusive option.  As you can see from the included patch, the changes to 
> > > vdsm
> > > are very limited.  In this model, VDSM interacts with MOM in the same way 
> > > as it
> > > uses libvirt.  Upon installation, VDSM installs its own MOM configuration 
> > > file
> > > and restarts the MOM daemon (which continues to exist as an independent
> > > system-level daemon).  Once restarted, MOM will load its policy from the 
> > > VDSM
> > > configuration directory.
> > > 
> > > Pros:
> > > - Simple and unobtrusive to either MOM or VDSM
> > > - Clean API with no duplication or layering
> > > - Maintain flexibility to tighten integration in the future
> > > 
> > > Cons:
> > > - Momd runs as root (like supervdsm)
> > > - If MOM will consume VDSM APIs, it must use the slower xmlrpc interface
> > 
> > I curious about the 'runs as root' bit. By listing it as a Con here,
> > you imply that if it were a VDSM thread, it could run as non-root ?
> > What is it that Momd has todo that requires root when run outside
> > of VDSM, yet is not a problem when inside VDSM ? IOW can it not be
> > made to run as 'momd' user/group when standalone ?
> 
> Very good questions -- thanks for raising them.  I've listed it as a con 
> because
> others have raised it as a concern.  MOM runs as root for a few reasons: to
> connect to the qemu:///system libvirt URI, to connect to guest agent sockets,
> and (most difficult to mitigate) to reconfigure KSM via sysfs.  As MOMs
> Controllers expand in functionality the need to root access will increase.

FWIW, connecitng to qemu:///system does not require root. Traditionally VDSM
configures SASL, so all that would be required is to create a SASL username
and password for Momd. Alternatively if the default policykit auth is in
effect for libvirtd, the mom RPM could simply drop a policy file into the
right location to allow processes under the 'momd' UNIX user to connect.

I don't have a clear answer for the KSM thing & other tunables momd might
need to deal with. There is perhaps a gap here for a system tunable daemon
to provide an RPC service over DBus, which momd then uses to change sysfs
tunables. Or something...

> The way vdsm works around this problem is that it spawns a 'supervdsm' process
> that has root privileges.  To make MOM work from within a VDSM thread, all
> root-requiring operations must be routed through the supervdsm API.  In my
> opinion, this is far from optimal and causes the MOM Controller API to become
> unnecessarily layered.  It also peppers the vdsm codebase with bits of
> privileged code.  Over time, this will become increasingly difficult to 
> manage.

Yeah, I think that is really sub-optimal from the security POV, because
both VDSM & supervdsm cover a very broad range of functionality so it
will be hard to offer a meaningful level of security policy acround
them, as compared to a dedicated Momd daemon.


> > IMHO, having a Momd that is a separate process from VDSM is pretty
> > desirable from the security POV. It is much more practical to write
> > a strict SELinux security policy for a fairly self-contained set of
> > functionality like Momd, than to write a policy for the very broad
> > functionality of VDSM as a whole.
> 
> I agree with this...
> 
> > 
> > Also, if Momd is separate, and talking to libvirt at all, then we
> > will also be able to take advantage of libvirt's future RBAC
> > controls, to strictly limit what changes Momd can do down to the
> > fine level of individual guests or groups of guests. eg you'll be
> > able to write SELinux policy that allows a process of type  'momd_t'
> > to only perform libvirt operations X & Y, against guests labelled
> > "svirt_BLAH_t" while allowing operations X, Y & Z against guest
> > labelled with "svirt_FOO_t".
> 
> ... and this.  Additionally, when running standalone, MOM can focus on being a
> system tuning mechanism.  Some tuning and stats collection will necessarily go
> through the VDSM API but some will not need to.  I think Plan A represents the
> UNIX model of orchestrating small components together to perform complex 
> tasks.
> 
> -- 
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
> 

-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to