1. 22 1月, 2010 2 次提交
  2. 21 1月, 2010 2 次提交
    • D
      Refactor setup & cleanup of security labels in security driver · 0c0e0d02
      Daniel P. Berrange 提交于
      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.
      
      NB, the AppArmour changes here haven't been compiled so may not
      build.
      0c0e0d02
    • D
      Make security drivers responsible for checking dynamic vs static labelling · 81fbb4cb
      Daniel P. Berrange 提交于
      The QEMU driver is doing 90% of the calls to check for static vs
      dynamic labelling. Except it is forgetting todo so in many places,
      in particular hotplug is mistakenly assigning disk labels. Move
      all this logic into the security drivers themselves, so the HV
      drivers don't have to think about it.
      
      * src/security/security_driver.h: Add virDomainObjPtr parameter
        to virSecurityDomainRestoreHostdevLabel and to
        virSecurityDomainRestoreSavedStateLabel
      * src/security/security_selinux.c, src/security/security_apparmor.c:
        Add explicit checks for VIR_DOMAIN_SECLABEL_STATIC and skip all
        chcon() code in those cases
      * src/qemu/qemu_driver.c: Remove all checks for VIR_DOMAIN_SECLABEL_STATIC
        or VIR_DOMAIN_SECLABEL_DYNAMIC. Add missing checks for possibly NULL
        driver entry points.
      81fbb4cb
  3. 13 11月, 2009 1 次提交
  4. 10 11月, 2009 1 次提交
  5. 04 11月, 2009 1 次提交
    • C
      Various error reporting fixes · 4c44cdcc
      Cole Robinson 提交于
      - Don't duplicate SystemError
      - Use proper error code in domain_conf
      - Fix a broken error call in qemu_conf
      - Don't use VIR_ERR_ERROR in security driver (isn't a valid code in this case)
      4c44cdcc
  6. 08 10月, 2009 1 次提交
    • J
      sVirt AppArmor security driver · bbaecd6a
      Jamie Strandboge 提交于
      * configure.in: look for AppArmor and devel
      * src/security/security_apparmor.[ch] src/security/security_driver.c
        src/Makefile.am: add and plug the new driver
      * src/security/virt-aa-helper.c: new binary which is used exclusively by
        the AppArmor security driver to manipulate AppArmor.
      * po/POTFILES.in: registers the new files
      * tests/Makefile.am tests/secaatest.c tests/virt-aa-helper-test:
        tests for virt-aa-helper and the security driver, secaatest.c is
        identical to seclabeltest.c except it initializes the 'apparmor'
        driver instead of 'selinux'
      bbaecd6a