1. 21 12月, 2012 7 次提交
  2. 18 12月, 2012 1 次提交
  3. 02 11月, 2012 1 次提交
  4. 23 10月, 2012 2 次提交
    • E
      build: print uids as unsigned · add633bd
      Eric Blake 提交于
      Reported by Michal Privoznik.
      
      * src/security/security_dac.c (virSecurityDACGenLabel): Use
      correct format.
      add633bd
    • E
      build: use correct printf types for uid/gid · 23a4df88
      Eric Blake 提交于
      Fixes a build failure on cygwin:
      cc1: warnings being treated as errors
      security/security_dac.c: In function 'virSecurityDACSetProcessLabel':
      security/security_dac.c:862:5: error: format '%u' expects type 'unsigned int', but argument 7 has type 'uid_t' [-Wformat]
      security/security_dac.c:862:5: error: format '%u' expects type 'unsigned int', but argument 8 has type 'gid_t' [-Wformat]
      
      * src/security/security_dac.c (virSecurityDACSetProcessLabel)
      (virSecurityDACGenLabel): Use proper casts.
      23a4df88
  5. 20 10月, 2012 1 次提交
    • E
      storage: use cache to walk backing chain · 38c4a9cc
      Eric Blake 提交于
      We used to walk the backing file chain at least twice per disk,
      once to set up cgroup device whitelisting, and once to set up
      security labeling.  Rather than walk the chain every iteration,
      which possibly includes calls to fork() in order to open root-squashed
      NFS files, we can exploit the cache of the previous patch.
      
      * src/conf/domain_conf.h (virDomainDiskDefForeachPath): Alter
      signature.
      * src/conf/domain_conf.c (virDomainDiskDefForeachPath): Require caller
      to supply backing chain via disk, if recursion is desired.
      * src/security/security_dac.c
      (virSecurityDACSetSecurityImageLabel): Adjust caller.
      * src/security/security_selinux.c
      (virSecuritySELinuxSetSecurityImageLabel): Likewise.
      * src/security/virt-aa-helper.c (get_files): Likewise.
      * src/qemu/qemu_cgroup.c (qemuSetupDiskCgroup)
      (qemuTeardownDiskCgroup): Likewise.
      (qemuSetupCgroup): Pre-populate chain.
      38c4a9cc
  6. 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
  7. 11 10月, 2012 1 次提交
  8. 09 10月, 2012 1 次提交
  9. 03 10月, 2012 1 次提交
    • M
      security: also parse user/group names instead of just IDs for DAC labels · 60469dd1
      Marcelo Cerri 提交于
      The DAC driver is missing parsing of group and user names for DAC labels
      and currently just parses uid and gid. This patch extends it to support
      names, so the following security label definition is now valid:
      
        <seclabel type='static' model='dac' relabel='yes'>
            <label>qemu:qemu</label>
            <imagelabel>qemu:qemu</imagelabel>
        </seclabel>
      
      When it tries to parse an owner or a group, it first tries to resolve it as
      a name, if it fails or it's an invalid user/group name then it tries to
      parse it as an UID or GID. A leading '+' can also be used for both owner and
      group to force it to be parsed as IDs, so the following example is also
      valid:
      
        <seclabel type='static' model='dac' relabel='yes'>
            <label>+101:+101</label>
            <imagelabel>+101:+101</imagelabel>
        </seclabel>
      
      This ensures that UID 101 and GUI 101 will be used instead of an user or
      group named "101".
      60469dd1
  10. 21 9月, 2012 1 次提交
  11. 20 9月, 2012 1 次提交
    • P
      security: Don't ignore errors when parsing DAC security labels · ede89aab
      Peter Krempa 提交于
      The DAC security driver silently ignored errors when parsing the DAC
      label and used default values instead.
      
      With a domain containing the following label definition:
      
      <seclabel type='static' model='dac' relabel='yes'>
        <label>sdfklsdjlfjklsdjkl</label>
      </seclabel>
      
      the domain would start normaly but the disk images would be still owned
      by root and no error was displayed.
      
      This patch changes the behavior if the parsing of the label fails (note
      that a not present label is not a failure and in this case the default
      label should be used) the error isn't masked but is raised that causes
      the domain start to fail with a descriptive error message:
      
      virsh #  start tr
      error: Failed to start domain tr
      error: internal error invalid argument: failed to parse DAC seclabel
      'sdfklsdjlfjklsdjkl' for domain 'tr'
      
      I also changed the error code to "invalid argument" from "internal
      error" and tweaked the various error messages to contain correct and
      useful information.
      ede89aab
  12. 29 8月, 2012 4 次提交
  13. 21 8月, 2012 2 次提交
  14. 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
  15. 24 5月, 2012 1 次提交
  16. 16 5月, 2012 2 次提交
  17. 02 3月, 2012 1 次提交
    • E
      build: use correct type for pid and similar types · 3e2c3d8f
      Eric Blake 提交于
      No thanks to 64-bit windows, with 64-bit pid_t, we have to avoid
      constructs like 'int pid'.  Our API in libvirt-qemu cannot be
      changed without breaking ABI; but then again, libvirt-qemu can
      only be used on systems that support UNIX sockets, which rules
      out Windows (even if qemu could be compiled there) - so for all
      points on the call chain that interact with this API decision,
      we require a different variable name to make it clear that we
      audited the use for safety.
      
      Adding a syntax-check rule only solves half the battle; anywhere
      that uses printf on a pid_t still needs to be converted, but that
      will be a separate patch.
      
      * cfg.mk (sc_correct_id_types): New syntax check.
      * src/libvirt-qemu.c (virDomainQemuAttach): Document why we didn't
      use pid_t for pid, and validate for overflow.
      * include/libvirt/libvirt-qemu.h (virDomainQemuAttach): Tweak name
      for syntax check.
      * src/vmware/vmware_conf.c (vmwareExtractPid): Likewise.
      * src/driver.h (virDrvDomainQemuAttach): Likewise.
      * tools/virsh.c (cmdQemuAttach): Likewise.
      * src/remote/qemu_protocol.x (qemu_domain_attach_args): Likewise.
      * src/qemu_protocol-structs (qemu_domain_attach_args): Likewise.
      * src/util/cgroup.c (virCgroupPidCode, virCgroupKillInternal):
      Likewise.
      * src/qemu/qemu_command.c(qemuParseProcFileStrings): Likewise.
      (qemuParseCommandLinePid): Use pid_t for pid.
      * daemon/libvirtd.c (daemonForkIntoBackground): Likewise.
      * src/conf/domain_conf.h (_virDomainObj): Likewise.
      * src/probes.d (rpc_socket_new): Likewise.
      * src/qemu/qemu_command.h (qemuParseCommandLinePid): Likewise.
      * src/qemu/qemu_driver.c (qemudGetProcessInfo, qemuDomainAttach):
      Likewise.
      * src/qemu/qemu_process.c (qemuProcessAttach): Likewise.
      * src/qemu/qemu_process.h (qemuProcessAttach): Likewise.
      * src/uml/uml_driver.c (umlGetProcessInfo): Likewise.
      * src/util/virnetdev.h (virNetDevSetNamespace): Likewise.
      * src/util/virnetdev.c (virNetDevSetNamespace): Likewise.
      * tests/testutils.c (virtTestCaptureProgramOutput): Likewise.
      * src/conf/storage_conf.h (_virStoragePerms): Use mode_t, uid_t,
      and gid_t rather than int.
      * src/security/security_dac.c (virSecurityDACSetOwnership): Likewise.
      * src/conf/storage_conf.c (virStorageDefParsePerms): Avoid
      compiler warning.
      3e2c3d8f
  18. 04 2月, 2012 1 次提交
    • L
      qemu: eliminate "Ignoring open failure" when using root-squash NFS · c18a88ac
      Laine Stump 提交于
      This eliminates the warning message reported in:
      
       https://bugzilla.redhat.com/show_bug.cgi?id=624447
      
      It was caused by a failure to open an image file that is not
      accessible by root (the uid libvirtd is running as) because it's on a
      root-squash NFS share, owned by a different user, with permissions of
      660 (or maybe 600).
      
      The solution is to use virFileOpenAs() rather than open(). The
      codepath that generates the error is during qemuSetupDiskCGroup(), but
      the actual open() is in a lower-level generic function called from
      many places (virDomainDiskDefForeachPath), so some other pieces of the
      code were touched just to add dummy (or possibly useful) uid and gid
      arguments.
      
      Eliminating this warning message has the nice side effect that the
      requested operation may even succeed (which in this case isn't
      necessary, but shouldn't hurt anything either).
      c18a88ac
  19. 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
  20. 12 12月, 2011 1 次提交
  21. 28 9月, 2011 1 次提交
    • L
      security: properly chown/label bidirectional and unidirectional fifos · 46e8dc71
      Laine Stump 提交于
      This patch fixes the regression with using named pipes for qemu serial
      devices noted in:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=740478
      
      The problem was that, while new code in libvirt looks for a single
      bidirectional fifo of the name given in the config, then relabels that
      and continues without looking for / relabelling the two unidirectional
      fifos named ${name}.in and ${name}.out, qemu looks in the opposite
      order. So if the user had naively created all three fifos, libvirt
      would relabel the bidirectional fifo to allow qemu access, but qemu
      would attempt to use the two unidirectional fifos and fail (because it
      didn't have proper permissions/rights).
      
      This patch changes the order that libvirt looks for the fifos to match
      what qemu does - first it looks for the dual fifos, then it looks for
      the single bidirectional fifo. If it finds the dual unidirectional
      fifos first, it labels/chowns them and ignores any possible
      bidirectional fifo.
      
      (Note commit d37c6a3a (which first appeared in libvirt-0.9.2) added
      the code that checked for a bidirectional fifo. Prior to that commit,
      bidirectional fifos for serial devices didn't work because libvirt
      always required the ${name}.(in|out) fifos to exist, and qemu would
      always prefer those.
      46e8dc71
  22. 31 8月, 2011 1 次提交
    • D
      Remove bogus virSecurityManagerSetProcessFDLabel method · 18338388
      Daniel P. Berrange 提交于
      The virSecurityManagerSetProcessFDLabel method was introduced
      after a mis-understanding from a conversation about SELinux
      socket labelling. The virSecurityManagerSetSocketLabel method
      should have been used for all such scenarios.
      
      * src/security/security_apparmor.c, src/security/security_apparmor.c,
        src/security/security_driver.h, src/security/security_manager.c,
        src/security/security_manager.h, src/security/security_selinux.c,
        src/security/security_stack.c: Remove SetProcessFDLabel driver
      18338388
  23. 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
  24. 28 6月, 2011 2 次提交
    • D
      Add a virSecurityManagerSetProcessFDLabel · 8e3c6fbb
      Daniel P. Berrange 提交于
      Add a new security driver method for labelling an FD with
      the process label, rather than the image label
      
      * src/libvirt_private.syms, 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_selinux.c, src/security/security_stack.c:
        Add virSecurityManagerSetProcessFDLabel & impl
      8e3c6fbb
    • D
      Rename virSecurityManagerSetFDLabel method · 4438c63e
      Daniel P. Berrange 提交于
      The virSecurityManagerSetFDLabel method is used to label
      file descriptors associated with disk images. There will
      shortly be a need to label other file descriptors in a
      different way. So the current name is ambiguous. Rename
      the method to virSecurityManagerSetImageFDLabel to clarify
      its purpose
      
      * src/libvirt_private.syms,
        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_selinux.c,
        src/security/security_stack.c: s/FDLabel/ImageFDLabel/
      4438c63e
  25. 04 6月, 2011 1 次提交
    • L
      security driver: ignore EINVAL when chowning an image file · 62ed801c
      Laine Stump 提交于
      This fixes:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=702044
        https://bugzilla.redhat.com/show_bug.cgi?id=709454
      
      Both of these complain of a failure to use an image file that resides
      on a read-only NFS volume. The function in the DAC security driver
      that chowns image files to the qemu user:group before using them
      already has special cases to ignore failure of chown on read-only file
      systems, and in a few other cases, but it hadn't been checking for
      EINVAL, which is what is returned if the qemu user doesn't even exist
      on the NFS server.
      
      Since the explanation of EINVAL in the chown man page almost exactly
      matches the log message already present for the case of EOPNOTSUPP,
      I've just added EINVAL to that same conditional.
      62ed801c
  26. 06 5月, 2011 1 次提交
    • D
      Fix security driver handling of FIFOs with QEMU · d37c6a3a
      Daniel P. Berrange 提交于
      When setting up a FIFO for QEMU, it allows either a pair
      of fifos used unidirectionally, or a single fifo used
      bidirectionally. Look for the bidirectional fifo first
      when labelling since that is more useful
      
      * src/security/security_dac.c,
        src/security/security_selinux.c: Fix fifo handling
      d37c6a3a