| Summary: | guestmount ignores AppArmor and the setting "security_require_confined = 1" | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Ralph <rm> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | NEW --- | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | ptoscano, rm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Ralph
2018-04-08 16:05:35 UTC
You may be right, but I've literally no idea how to fix this or even what component should be responsible. For SELinux/sVirt, we only support that when using the 'libvirt' backend, and we do make a few small changes to the XML (mainly to work around problems). It may be for AppArmor we also need to change the libvirt XML -- it's my understanding that libvirt can use AppArmor when available. Which distribution is this? Can you please list the exact versions of libguestfs and libvirt packages? (In reply to Pino Toscano from comment #2) > Which distribution is this? > Can you please list the exact versions of libguestfs and libvirt packages? Distribution is Opensuse Leap 42.3. Packages with version numbers there: guestfs-data 1.32.4-10.10 (standard Leap 42.3 OSS repository) guestfs-tools 1.32.4.10.10 (standard Leap 42.3 OSS repository) libguestfs0 1.32.4.10.10 (standard Leap 42.3 OSS repository) libvirt 3.3.0-12.1 (standard Leap 42.3 Update Repository) The same for all other libvirt packages libapparnmor1 2.10.3-16.1 (standard Leap 42.3 Update Repository) The same for all other apparmor packages Sorry, that I have no Red Hat distribution available at the site where the problem came up. Hope the information helps nevertheless Regarding the standard KVM/QEMU-guest-machines (Kali 2018, Debian Jessie, Opensuse Leap 42.3) for testing the use of Apparmor security profiles => created and started with virt-manager by standard unprivileged user. Apparmor profile-files for the virtual machines are created in /etc/apparmor.d/libvirt/ the first time the guests are started. These profiles are used later on. This does not happen if an unprivileged user starts guestmount and the supermin QEMU-machine. (In reply to Richard W.M. Jones from comment #1) > You may be right, but I've literally no idea how to fix this or even > what component should be responsible. For SELinux/sVirt, we only support > that when using the 'libvirt' backend, and we do make a few small changes > to the XML (mainly to work around problems). It may be for AppArmor > we also need to change the libvirt XML -- it's my understanding that > libvirt can use AppArmor when available. It seems to be complicated to my very limited understanding. All parts (libguestfs, libvirt and apparmor) are involved somehow. The first remarkable thing is the user/UID who/wich is assigned to the the process for the QEMU-machine: When virt-manager/libvirt is used by an unprivileged user (who, however, is member of the libvirt group) to start a normal KVM/Qemu-guest-machine the user for the qemu-process is "qemu". In case of guestmount the started QEMU-machine is assigned to the UID of the unprivileged user. This shows already that the qemu-machines are handled differently. This may have an impact on rights and the required creation of an Apparmor profile for the qemu-machine. Another question is whether, where and how to create/delete an Apparmor profile for a qemu-machine which is only temporarily (!) used. And which has no permanent UUID. Should this be a kind of standard profile which is kept permanently ? Or should it be deleted again at the point when a libguestfs-tool is stopped ? (In reply to Ralph from comment #4) > The first remarkable thing is the user/UID who/wich is assigned to the the > process for the QEMU-machine: > > When virt-manager/libvirt is used by an unprivileged user (who, however, is > member of the libvirt group) to start a normal KVM/Qemu-guest-machine the > user for the qemu-process is "qemu". This is because when you run virt-manager as non-root, it uses policykit (or some similar mechanism) to elevate its libvirt privileges to root. > In case of guestmount the started QEMU-machine is assigned to the UID of the > unprivileged user. This is correct, and is how it should be. The bug is that when we run libguestfs as root, libvirt runs qemu as a non-root user (qemu.qemu) (https://bugzilla.redhat.com/show_bug.cgi?id=890291) instead of root. > This shows already that the qemu-machines are handled differently. This may > have an impact on rights and the required creation of an Apparmor profile > for the qemu-machine. I don't think this conclusion is correct, as you are misunderstanding how virt-manager / policykit works - see above. (In reply to Richard W.M. Jones from comment #5) > (In reply to Ralph from comment #4) > > The bug is that when we run libguestfs as root, libvirt runs qemu as a > non-root > user (qemu.qemu) (https://bugzilla.redhat.com/show_bug.cgi?id=890291) > instead of root. > > > This shows already that the qemu-machines are handled differently. This may > > have an impact on rights and the required creation of an Apparmor profile > > for the qemu-machine. > > I don't think this conclusion is correct, as you are misunderstanding how > virt-manager / policykit works - see above. As I am no expert, yes, I probably misunderstand the privilege handling between a non-root user and libvirt. However, I agree that libvirt gets root privileges by whatever policy rules when I start a normal virtual machine (not a libguestfs-qemu-machine) via "virt-manager". It then assigns the QEMU process to user "qemu". Now back to guestmount. To avoid misunderstandings, I want to separate different aspects of the problem for different types of users more clearly: Assumptions for a test: The img-file W7_x64_ssdx.vmdk has access rights for everybody (777). It is not located in the /root-directory, but in /vmtest/sddx - which I made also fully accessible. Situation 1 - for user rmx: ------------ rmx starts guestmount with (!) delegation of the start of the libguestfs qemu-machine to libvirt. From the options chosen for the qemu-machine one can see that really libvirt started the machine; the options are different in case rmx does not delegate to libvirt. Then the resulting user for the qemu process is 'rmx' and not 'qemu'. This may be OK. However: 1) Apparmor is ignored by libvirt - despite security settings in /etc/libvirt/qemu.conf. We end up with "security-model:none" for the libguestfs-qemu-machine. This is the real bug I am addressing. 2) Consistently, no apparmor profile-file is written to /etc/apparmor.d/libvirt. (Due to whatever reasons - lack of privileges included) Situation 2 - for user root: ------------ root starts guestmount for the same img-file accessible to everybody and NOT even located in the /root-directory. root delegates the start of the libguestfs-qemu-machine to libvirt (# export LIBGUESTFS_ATTACH_METHOD=libvirt). Then: 1) An apparmor profile-file for the libguestfs-qemu-machine IS written into /etc/apparmor.d/libvirt. So, obviously, libvirt now follows the sec-settings in qemu.conf. 2) However, the process for the start of the qemu-machine fails with the following error message: # guestmount -a /vmtest/ssdx/W7_x64_ssdx.vmdk -m /dev/sda2 --ro /mnt3 libguestfs: error: could not create appliance through libvirt. Try running qemu directly without libvirt using this environment variable: export LIBGUESTFS_BACKEND=direct Original error from libvirt: internal error: process exited while connecting to monitor: 2018-04-09T11:49:06.055520Z qemu-system-x86_64: -drive file=/tmp/libguestfsCvfwxs/overlay1,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=unsafe: Could not open backing file: Could not open '/vmtest/ssdx/W7_x64_ssdx.vmdk': Permission denied [code=1 int1=-1] Which seems to be strange taking into account the file access rights - but probably other policies get hurt, too. Actually, I cannot see which user is chosen to start the qemu-process - it may be qemu.qemu in this case. I think what happens in situation 2 has indeed a lot to do with https://bugzilla.redhat.com/show_bug.cgi?id=890291. But isn't the problem occurring in situation 1 not a bit different? |