A pool-operator can enable execution of arbitrary scripts within guest VMs by setting Pool.other_config:allow_guest_agent_run_script to "true". This key controls the guest-agent-operation plugin's run-script capability pool-wide. Once enabled, the pool-operator (or any attacker who has escalated to pool-operator) can execute commands inside any VM that has the guest agent installed. This is a privilege escalation from host-level management to guest-level code execution, crossing the host-guest trust boundary. With the BOC-1 chain, a vm-admin can reach this vector via RBAC collapse.
Pool.other_config is a Map(String, String) field writable by pool-operator. The allow_guest_agent_run_script key is checked at helpers.ml:1398-1405. When set to "true", the guest agent operation plugin's script execution capability is enabled for every VM in the pool that has the guest agent installed.
The code path:
pool-operator calls Pool.add_to_other_config(pool, "allow_guest_agent_run_script", "true")helpers.ml:1398-1405 checks this key value"true", the guest agent's run-script operation is permittedPool.other_config is the highest-scope other_config field in the XAPI data model - a single key write affects behavior across every host and VM in the pool.
Missing RBAC protection. Pool.other_config has zero map_keys_roles entries for the allow_guest_agent_run_script key. Any pool-operator can enable it.
Missing validation. No confirmation prompt, no audit trail, no time-bounded enablement. The flag stays set until explicitly removed.
Scope mismatch. A host-level administrative action (pool-operator) enables guest-level code execution - a cross-boundary privilege escalation that should require explicit pool-admin authorization.
Insufficient logging. No security alert is generated when this pool-wide execution capability is enabled.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Host-to-guest code execution | Execute arbitrary scripts inside any VM with guest agent | pool-operator credential, guest agent installed | Source-traced |
| Cross-tenant command execution | Execute commands in tenant VMs in multi-tenant deployments | pool-operator, multiple tenants | Modeled |
| Persistent backdoor | Install persistent access in guest VMs via script execution | pool-operator, writable guest filesystem | Modeled |
| Via BOC-1 chain | vm-admin escalates to pool-operator via BOC-1 S3, then enables guest agent script execution | BOC-1 available | Modeled (chained) |
Pool.other_config for the allow_guest_agent_run_script keydisclosure/vendor-detection-guidance.mdPool.other_config for the allow_guest_agent_run_script key and remove if presentRestrict to pool-admin. Protect allow_guest_agent_run_script via map_keys_roles at _R_POOL_ADMIN.
Add confirmation and audit. Require explicit confirmation when enabling guest agent script execution. Log the enablement as a security-relevant event.
Time-bounded enablement. Implement an automatic expiry for this flag rather than leaving it permanently enabled.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
helpers.ml:1398-1405 (key check), datamodel.ml (Pool field definition)disclosure/advisories/ploc-security-advisory.md (PLOC-3)research/investigations/pool-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.