Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1885341

Summary: Enabling qemu guest agent file and exec api by default
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: David Vossel <dvossel>
Component: qemu-kvmAssignee: Marc-Andre Lureau <marcandre.lureau>
qemu-kvm sub component: Guest Agent QA Contact: dehanmeng <demeng>
Status: CLOSED WONTFIX Docs Contact:
Severity: unspecified    
Priority: medium CC: berrange, fdeutsch, jgreguske, jinzhao, juzhang, jwboyer, lijin, virt-maint, xiagao
Version: ---Keywords: RFE
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-12 12:42:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Vossel 2020-10-05 16:22:40 UTC
Description of problem:

The file and exec qemu guest agent commands are disabled by default on the rhel guest images. This can be seen by inspecting the /etc/sysconfig/qemu-ga configuration that's shipped with the guest agent.

Example:
# cat /etc/sysconfig/qemu-ga | grep BLACKLIST_RPC
BLACKLIST_RPC=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status

OpenShift Virtualization is interested in leveraging these guest agent APIs to provide some advanced functionality around dynamically managing access credentials in the guest. For this to work as intended, we'd need these commands enabled by default to provide a consistent user experience.

Typically when we think about VM guest isolation, the concern is about the guest breaking into the host and not necessarily the host breaking into the guest. This request is to re-evaluate why these commands are disabled and see if can consider enabling them

Comment 1 John Ferlan 2020-10-05 17:29:41 UTC
Moving this to RHEL-AV first and adding CNV as the dependent product.  Once something is completed in RHEL-AV, then we can decide where it needs to be cloned for RHEL.

Comment 2 Daniel Berrangé 2020-10-06 09:04:56 UTC
(In reply to David Vossel from comment #0)
> OpenShift Virtualization is interested in leveraging these guest agent APIs
> to provide some advanced functionality around dynamically managing access
> credentials in the guest. For this to work as intended, we'd need these
> commands enabled by default to provide a consistent user experience.

Can you provide further technical information on what specific tasks you're trying to accomplish. 

Directly manipulating files / executing commands is not a great fit for the guest agent, as these things vary across different guest OS, especially when considering Windows vs UNIX platforms. The guest agent isn't providing sufficient visibility of the guest OS to let the host mgmtm reliabily figure out the right files/commands to use.

The general strategy for the QEMU guest agent (and oVirt and spice agents) has thus been to provide task specific commands that mgmt apps needs. These commands can be implemented with portability in mind.

Comment 3 Marc-Andre Lureau 2020-10-06 09:08:02 UTC
One of them is bug 1885332. (if it's the only one, we may end up closing as duplicate)

Comment 4 Fabian Deutsch 2020-10-08 08:34:28 UTC
> Can you provide further technical information on what specific tasks you're trying to accomplish. 

As Marc-Andre already mentioned, this bug is to enable a short term solution before we get bug #1885332 fixed.

Comment 5 Daniel Berrangé 2020-10-08 10:14:12 UTC
(In reply to Fabian Deutsch from comment #4)
> > Can you provide further technical information on what specific tasks you're trying to accomplish. 
> 
> As Marc-Andre already mentioned, this bug is to enable a short term solution
> before we get bug #1885332 fixed.

In that case, I'd not be in favour of enabling the file / exec APIs. That has a ripple effect because it opens up the guest agent to be able to change arbitrary files in the OS, which is something the SELinux policy intentionally forbids right now to attempt to limit the impact of a flaw in the guest agent code. Once we open the file/exec APIs it will impossible to turn them back off, as we'll not be sure what other usage has been introduced.

The bug #1885332 sounds simple enough that it should be practical to get it implemented in a reasonably short period of time, negating the need for this even in the short term.

Comment 6 David Vossel 2020-10-12 12:42:55 UTC
> The bug #1885332 sounds simple enough that it should be practical to get it implemented in a reasonably short period of time, negating the need for this even in the short term.

excellent, sounds great to me.

I'll closing this BZ for now, lets focus on the well defined api