- 21 12月, 2012 7 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
- 18 12月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
When LXC labels USB devices during hotplug, it is running in host context, so it needs to pass in a vroot path to the container root. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 02 11月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The libvirt coding standard is to use 'function(...args...)' instead of 'function (...args...)'. A non-trivial number of places did not follow this rule and are fixed in this patch. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 23 10月, 2012 2 次提交
-
-
由 Eric Blake 提交于
Reported by Michal Privoznik. * src/security/security_dac.c (virSecurityDACGenLabel): Use correct format.
-
由 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.
-
- 20 10月, 2012 1 次提交
-
-
由 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.
-
- 15 10月, 2012 1 次提交
-
-
由 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)
-
- 11 10月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
All USB device lookup functions emit an error when they cannot find the requested device. With this patch, their caller can choose if a missing device is an error or normal condition.
-
- 09 10月, 2012 1 次提交
-
-
由 Marcelo Cerri 提交于
The functions virGetUserID and virGetGroupID are now able to parse user/group names and IDs in a similar way to coreutils' chown. So, user and group parsing in security_dac can be simplified.
-
- 03 10月, 2012 1 次提交
-
-
由 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".
-
- 21 9月, 2012 1 次提交
-
-
由 Eric Blake 提交于
https://www.gnu.org/licenses/gpl-howto.html recommends that the 'If not, see <url>.' phrase be a separate sentence. * tests/securityselinuxhelper.c: Remove doubled line. * tests/securityselinuxtest.c: Likewise. * globally: s/; If/. If/
-
- 20 9月, 2012 1 次提交
-
-
由 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.
-
- 29 8月, 2012 4 次提交
-
-
由 Alex Jia 提交于
* src/security/security_dac.c: remove useless dead code. Signed-off-by: NAlex Jia <ajia@redhat.com>
-
由 Peter Krempa 提交于
As in the previous commit, images are also chowned to uninitialised uid and gid if the label is not present.
-
由 Peter Krempa 提交于
When starting a machine the DAC security driver tries to set the UID and GID of the newly spawned process. This worked as desired if the desired label was set. When the label was missing a logical bug in virSecurityDACGenLabel() caused that uninitialised values were used as uid and gid for the new process. With this patch, default values (from qemu driver configuration) are used if the label is not found.
-
由 Peter Krempa 提交于
When no DAC "label" was requested for a domain the DAC manager tried to strdup a NULL string causing a segfault.
-
- 21 8月, 2012 2 次提交
-
-
由 Daniel P. Berrange 提交于
The DAC security driver uses the virStrToLong_ui function to parse the uid/gid out of the seclabel string. This works on Linux where 'uid_t' is an unsigned int, but on Mingw32 it is just an 'int'. This causes compiler warnings about signed/ unsigned int pointer mis-match. To avoid this, use explicit 'unsigned int ouruid' local vars to pass into virStrToLong_ui, and then simply assign to the 'uid_t' type after parsing Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Marcelo Cerri 提交于
These changes make the security drivers able to find and handle the correct security label information when more than one label is available. They also update the DAC driver to be used as an usual security driver. Signed-off-by: NMarcelo Cerri <mhcerri@linux.vnet.ibm.com>
-
- 23 7月, 2012 1 次提交
-
-
由 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
-
- 24 5月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
-
- 16 5月, 2012 2 次提交
-
-
由 Daniel Walsh 提交于
Some security drivers require special options to be passed to the mount system call. Add a security driver API for handling this data. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel Walsh 提交于
To allow the security drivers to apply different configuration information per hypervisor, pass the virtualization driver name into the security manager constructor. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 02 3月, 2012 1 次提交
-
-
由 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.
-
- 04 2月, 2012 1 次提交
-
-
由 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).
-
- 11 1月, 2012 1 次提交
-
-
由 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
-
- 12 12月, 2011 1 次提交
-
-
由 Josh Durgin 提交于
Network disks don't have paths to be resolved or files to be checked for ownership. ee3efc41 checked this for some image label functions, but was partially reverted in a refactor. This finishes adding the check to each security driver's set and restore label methods for images. Signed-off-by: NJosh Durgin <josh.durgin@dreamhost.com>
-
- 28 9月, 2011 1 次提交
-
-
由 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.
-
- 31 8月, 2011 1 次提交
-
-
由 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
-
- 26 8月, 2011 2 次提交
-
-
由 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).
-
由 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.
-
- 28 6月, 2011 2 次提交
-
-
由 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
-
由 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/
-
- 04 6月, 2011 1 次提交
-
-
由 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.
-
- 06 5月, 2011 1 次提交
-
-
由 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
-