On Wed, 2010-01-20 at 17:19 +0100, Daniel Veillard wrote:
> On Wed, Jan 20, 2010 at 03:14:59PM +0000, Daniel P. Berrange wrote:
> > The current security driver architecture has the following
> > split of logic
> >
> > * domainGenSecurityLabel
> >
> > Allocate the unique label for the domain about to be started
> >
> > * domainGetSecurityLabel
> >
> > Retrieve the current live security label for a process
> >
> > * domainSetSecurityLabel
> >
> > Apply the previously allocated label to the current process
> > Setup all disk image / device labelling
> >
> > * domainRestoreSecurityLabel
> >
> > Restore the original disk image / device labelling.
> > Release the unique label for the domain
> >
> > The 'domainSetSecurityLabel' method is special because it runs
> > in the context of the child process between the fork + exec.
> >
> > This is require in order to set the process label. It is not
> > required in order to label disks/devices though. Having the
> > disk labelling code run in the child process limits what it
> > can do.
> >
> > In particularly libvirtd would like to remember the current
> > disk image label, and only change shared image labels for the
> > first VM to start. This requires use & update of global state
> > in the libvirtd daemon, and thus cannot run in the child
> > process context.
> >
> > The solution is to split domainSetSecurityLabel into two parts,
> > one applies process label, and the other handles disk image
> > labelling. At the same time domainRestoreSecurityLabel is
> > similarly split, just so that it matches the style. Thus the
> > previous 4 methods are replaced by the following 6 new methods
> >
> > * domainGenSecurityLabel
> >
> > Allocate the unique label for the domain about to be started
> > No actual change here.
> >
> > * domainReleaseSecurityLabel
> >
> > Release the unique label for the domain
> >
> > * domainGetSecurityProcessLabel
> >
> > Retrieve the current live security label for a process
> > Merely renamed for clarity.
> >
> > * domainSetSecurityProcessLabel
> >
> > Apply the previously allocated label to the current process
> >
> > * domainRestoreSecurityAllLabel
> >
> > Restore the original disk image / device labelling.
> >
> > * domainSetSecurityAllLabel
> >
> > Setup all disk image / device labelling
> >
> > The SELinux and AppArmour drivers are then updated to comply with
> > this new spec. Notice that the AppArmour driver was actually a
> > little different. It was creating its profile for the disk image
> > and device labels in the 'domainGenSecurityLabel' method, where as
> > the SELinux driver did it in 'domainSetSecurityLabel'. With the
> > new method split, we can have consistency, with both drivers doing
> > that in the domainSetSecurityAllLabel method.
>
> A bit complex, thanks for the explanations !
>
> > NB, the AppArmour changes here haven't been compiled so may not
> > build.
> > ---
> > src/qemu/qemu_driver.c | 21 ++++++++---
> > src/security/security_apparmor.c | 66 ++++++++++++++++++++++-----------
> > src/security/security_driver.h | 30 +++++++++------
> > src/security/security_selinux.c | 75 +++++++++++++++++++++++++-------------
> > 4 files changed, 127 insertions(+), 65 deletions(-)
> [...]
> > +static int
> > +SELinuxSetSecurityAllLabel(virConnectPtr conn,
> > + virDomainObjPtr vm)
> > +{
> > + const virSecurityLabelDefPtr secdef = &vm->def->seclabel;
> > + int i;
> > +
> > + if (secdef->type == VIR_DOMAIN_SECLABEL_STATIC)
> > + return 0;
> > +
> > + for (i = 0 ; i < vm->def->ndisks ; i++) {
> > + /* XXX fixme - we need to recursively label the entriy tree :-( */
>
> while we're are there let's fix the entriy/entire typo
Not sure what this is supposed to mean, but you could exec chcon -R on
the directory tree if you want to recursively relabel it.
--
Stephen Smalley
National Security Agency
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list