1. 15 10月, 2012 1 次提交
    • G
      selinux: add security selinux function to label tapfd · ae368ebf
      Guannan Ren 提交于
      BZ:https://bugzilla.redhat.com/show_bug.cgi?id=851981
      When using macvtap, a character device gets first created by
      kernel with name /dev/tapN, its selinux context is:
      system_u:object_r:device_t:s0
      
      Shortly, when udev gets notification when new file is created
      in /dev, it will then jump in and relabel this file back to the
      expected default context:
      system_u:object_r:tun_tap_device_t:s0
      
      There is a time gap happened.
      Sometimes, it will have migration failed, AVC error message:
      type=AVC msg=audit(1349858424.233:42507): avc:  denied  { read write } for
      pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524
      scontext=unconfined_u:system_r:svirt_t:s0:c598,c908
      tcontext=system_u:object_r:device_t:s0 tclass=chr_file
      
      This patch will label the tapfd device before qemu process starts:
      system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label)
      ae368ebf
  2. 21 9月, 2012 1 次提交
  3. 23 7月, 2012 1 次提交
    • O
      Desert the FSF address in copyright · f9ce7dad
      Osier Yang 提交于
      Per the FSF address could be changed from time to time, and GNU
      recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
      
        You should have received a copy of the GNU General Public License
        along with Foobar.  If not, see <http://www.gnu.org/licenses/>.
      
      This patch removes the explicit FSF address, and uses above instead
      (of course, with inserting 'Lesser' before 'General').
      
      Except a bunch of files for security driver, all others are changed
      automatically, the copyright for securify files are not complete,
      that's why to do it manually:
      
        src/security/security_selinux.h
        src/security/security_driver.h
        src/security/security_selinux.c
        src/security/security_apparmor.h
        src/security/security_apparmor.c
        src/security/security_driver.c
      f9ce7dad
  4. 24 5月, 2012 1 次提交
  5. 16 5月, 2012 2 次提交
  6. 11 1月, 2012 1 次提交
    • D
      Change security driver APIs to use virDomainDefPtr instead of virDomainObjPtr · 99be754a
      Daniel P. Berrange 提交于
      When sVirt is integrated with the LXC driver, it will be neccessary
      to invoke the security driver APIs using only a virDomainDefPtr
      since the lxc_container.c code has no virDomainObjPtr available.
      Aside from two functions which want obj->pid, every bit of the
      security driver code only touches obj->def. So we don't need to
      pass a virDomainObjPtr into the security drivers, a virDomainDefPtr
      is sufficient. Two functions also gain a 'pid_t pid' argument.
      
      * src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c,
        src/qemu/qemu_migration.c, src/qemu/qemu_process.c,
        src/security/security_apparmor.c,
        src/security/security_dac.c,
        src/security/security_driver.h,
        src/security/security_manager.c,
        src/security/security_manager.h,
        src/security/security_nop.c,
        src/security/security_selinux.c,
        src/security/security_stack.c: Change all security APIs to use a
        virDomainDefPtr instead of virDomainObjPtr
      99be754a
  7. 26 8月, 2011 2 次提交
    • J
      security: Introduce SetSocketLabel · 520d91f8
      Jiri Denemark 提交于
      This API labels all sockets created until ClearSocketLabel is called in
      a way that a vm can access them (i.e., they are labeled with svirt_t
      based label in SELinux).
      520d91f8
    • J
      security: Rename SetSocketLabel APIs to SetDaemonSocketLabel · 4c85d96f
      Jiri Denemark 提交于
      The APIs are designed to label a socket in a way that the libvirt daemon
      itself is able to access it (i.e., in SELinux the label is virtd_t based
      as opposed to svirt_* we use for labeling resources that need to be
      accessed by a vm). The new name reflects this.
      4c85d96f
  8. 26 1月, 2011 1 次提交
    • L
      Add a function to the security driver API that sets the label of an open fd. · d89608f9
      Laine Stump 提交于
      A need was found to set the SELinux context label on an open fd (a
      pipe, as a matter of fact). This patch adds a function to the security
      driver API that will set the label on an open fd to secdef.label. For
      all drivers other than the SELinux driver, it's a NOP. For the SElinux
      driver, it calls fsetfilecon().
      
      If the return is a failure, it only returns error up to the caller if
      1) the desired label is different from the existing label, 2) the
      destination fd is of a type that supports setting the selinux context,
      and 3) selinux is in enforcing mode. Otherwise it will return
      success. This follows the pattern of the existing function
      SELinuxSetFilecon().
      d89608f9
  9. 11 1月, 2011 1 次提交
    • D
      Refactor the security drivers to simplify usage · d6623003
      Daniel P. Berrange 提交于
      The current security driver usage requires horrible code like
      
          if (driver->securityDriver &&
              driver->securityDriver->domainSetSecurityHostdevLabel &&
              driver->securityDriver->domainSetSecurityHostdevLabel(driver->securityDriver,
                                                                    vm, hostdev) < 0)
      
      This pair of checks for NULL clutters up the code, making the driver
      calls 2 lines longer than they really need to be. The goal of the
      patchset is to change the calling convention to simply
      
        if (virSecurityManagerSetHostdevLabel(driver->securityDriver,
                                              vm, hostdev) < 0)
      
      The first check for 'driver->securityDriver' being NULL is removed
      by introducing a 'no op' security driver that will always be present
      if no real driver is enabled. This guarentees driver->securityDriver
      != NULL.
      
      The second check for 'driver->securityDriver->domainSetSecurityHostdevLabel'
      being non-NULL is hidden in a new abstraction called virSecurityManager.
      This separates the driver callbacks, from main internal API. The addition
      of a virSecurityManager object, that is separate from the virSecurityDriver
      struct also allows for security drivers to carry state / configuration
      information directly. Thus the DAC/Stack drivers from src/qemu which
      used to pull config from 'struct qemud_driver' can now be moved into
      the 'src/security' directory and store their config directly.
      
      * src/qemu/qemu_conf.h, src/qemu/qemu_driver.c: Update to
        use new virSecurityManager APIs
      * src/qemu/qemu_security_dac.c,  src/qemu/qemu_security_dac.h
        src/qemu/qemu_security_stacked.c, src/qemu/qemu_security_stacked.h:
        Move into src/security directory
      * src/security/security_stack.c, src/security/security_stack.h,
        src/security/security_dac.c, src/security/security_dac.h: Generic
        versions of previous QEMU specific drivers
      * src/security/security_apparmor.c, src/security/security_apparmor.h,
        src/security/security_driver.c, src/security/security_driver.h,
        src/security/security_selinux.c, src/security/security_selinux.h:
        Update to take virSecurityManagerPtr object as the first param
        in all callbacks
      * src/security/security_nop.c, src/security/security_nop.h: Stub
        implementation of all security driver APIs.
      * src/security/security_manager.h, src/security/security_manager.c:
        New internal API for invoking security drivers
      * src/libvirt.c: Add missing debug for security APIs
      d6623003