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
> 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
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
> 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