1. 14 2月, 2013 1 次提交
    • L
      security: add new virSecurityManagerSetChildProcessLabel API · 7bf1aa0b
      Laine Stump 提交于
      The existing virSecurityManagerSetProcessLabel() API is designed so
      that it must be called after forking the child process, but before
      exec'ing the child. Due to the way the virCommand API works, that
      means it needs to be put in a "hook" function that virCommand is told
      to call out to at that time.
      
      Setting the child process label is a basic enough need when executing
      any process that virCommand should have a method of doing that. But
      virCommand must be told what label to set, and only the security
      driver knows the answer to that question.
      
      The new virSecurityManagerSet*Child*ProcessLabel() API is the way to
      transfer the knowledge about what label to set from the security
      driver to the virCommand object. It is given a virCommandPtr, and each
      security driver calls the appropriate virCommand* API to tell
      virCommand what to do between fork and exec.
      
      1) in the case of the DAC security driver, it calls
      virCommandSetUID/GID() to set a uid and gid that must be set for the
      child process.
      
      2) for the SELinux security driver, it calls
      virCommandSetSELinuxLabel() to save a copy of the char* that will be
      sent to setexeccon_raw() *after forking the child process*.
      
      3) for the AppArmor security drivers, it calls
      virCommandSetAppArmorProfile() to save a copy of the char* that will
      be sent to aa_change_profile() *after forking the child process*.
      
      With this new API in place, we will be able to remove
      virSecurityManagerSetProcessLabel() from any virCommand pre-exec
      hooks.
      
      (Unfortunately, the LXC driver uses clone() rather than virCommand, so
      it can't take advantage of this new security driver API, meaning that
      we need to keep around the older virSecurityManagerSetProcessLabel(),
      at least for now.)
      7bf1aa0b
  2. 12 2月, 2013 3 次提交
    • D
      Fix potential deadlock across fork() in QEMU driver · 61b52d2e
      Daniel P. Berrange 提交于
      The hook scripts used by virCommand must be careful wrt
      accessing any mutexes that may have been held by other
      threads in the parent process. With the recent refactoring
      there are 2 potential flaws lurking, which will become real
      deadlock bugs once the global QEMU driver lock is removed.
      
      Remove use of the QEMU driver lock from the hook function
      by passing in the 'virQEMUDriverConfigPtr' instance directly.
      
      Add functions to the virSecurityManager to be invoked before
      and after fork, to ensure the mutex is held by the current
      thread. This allows it to be safely used in the hook script
      in the child process.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      61b52d2e
    • E
      build: fix compilation of selinux on RHEL 5 · 736a87b9
      Eric Blake 提交于
      On RHEL 5, I got:
      
      security/security_selinux.c: In function 'getContext':
      security/security_selinux.c:971: warning: unused parameter 'mgr' [-Wunused-parameter]
      
      * src/security/security_selinux.c (getContext): Mark potentially
      unused parameter.
      736a87b9
    • D
      Remove re-entrant API call in SELinux/AppArmor security managers · 0ab49601
      Daniel P. Berrange 提交于
      The security manager drivers are not allowed to call back
      out to top level security manager APIs, since that results
      in recursive mutex acquisition and thus deadlock. Remove
      calls to virSecurityManagerGetModel from SELinux / AppArmor
      drivers
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0ab49601
  3. 11 2月, 2013 2 次提交
  4. 08 2月, 2013 1 次提交
  5. 06 2月, 2013 2 次提交
  6. 24 1月, 2013 4 次提交
  7. 23 1月, 2013 1 次提交
  8. 22 1月, 2013 2 次提交
  9. 21 12月, 2012 13 次提交
  10. 19 12月, 2012 2 次提交
  11. 18 12月, 2012 5 次提交
  12. 17 12月, 2012 1 次提交
    • D
      Support custom 'svirt_tcg_t' context for TCG based guests · 77d3a809
      Daniel P. Berrange 提交于
      The current SELinux policy only works for KVM guests, since
      TCG requires the 'execmem' privilege. There is a 'virt_use_execmem'
      boolean to turn this on globally, but that is unpleasant for users.
      This changes libvirt to automatically use a new 'svirt_tcg_t'
      context for TCG based guests. This obsoletes the previous
      boolean tunable and makes things 'just work(tm)'
      
      Since we can't assume we run with new enough policy, I also
      make us log a warning message (once only) if we find the policy
      lacks support. In this case we fallback to the normal label and
      expect users to set the boolean tunable
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      77d3a809
  13. 14 12月, 2012 1 次提交
  14. 12 12月, 2012 2 次提交