Hey Robbie! Thanks for picking this up, and you're right that it's a fair thing to bring up; you've understood the mechanism correctly. The new plugin manager does download and execute code. In `internal/plugin/manager/pluginengine.go` the `downloadStep` fetches a tarball from a GCS signed URL supplied in an "Agent Communication Service" (ACS) message, verifies a sha256 that arrives in that same message (L:140), unpacks it, and `launchStep` execs the entry point. I'll be upfront about the two worst parts: there's no independent code signature, and it runs as root (`google-guest-agent-manager.service` sets no `User=`) with only `cgroup` CPU/memory caps (`pluginlauncher.go:155`) so no sandboxing.
But what I'd push back on is that it's "equivalent to giving the host a root shell it can use at any time", because that property predates this change. This same source package already ships `google_metadata_script_runner`, which fetches `startup- script`/`shutdown-script` from the metadata server and runs them as root. Anyone holding `compute.instances.setMetadata` on the project has had arbitrary root execution in the guest all this time, it's inherent to how the guest agent works. The plugin manager is a second path to a capability the trust model already grants, so I'd argue it's not a new grant. And FWIW it's also not an open listener. The agent dials *out* to `agentcommunication.googleapis.com:443` over TLS, authenticating with an instance identity token pulled from the metadata server. It self- disables if the instance has no service account or isn't in the default "universe" (`internal/acs/client/client.go` Lines:360-407). The handler rejects any manifest that isn't `DYNAMIC_INSTALLATION` outright and always ignores requests targeting the core plugin (`internal/acs/handler/handler.go` Lines:196-210), so ACS can't replace the binary we end up shipping. All that said, two of your concerns do stand and I want them recorded for posterity. Firstly, the integrity rests entirely on the authenticity of that ACS channel plus an in-band checksum (i.e. there's no signing key to verify against). Secondly and more important for main: these dynamic plugin binaries never pass through the archive, so they get no Ubuntu community review, no CVE tracking and no security updates from our side. That's a policy question about what "in main" means here, and I don't think it's mine to answer so I'd rather get the Security Team's view than just wave it through. Would you want it scoped to the ACS --> plugin execution path specifically? (For completeness ACS can be disabled wholesale via `acs_client = false` under `[Core]` in the `/etc/default/instance_configs.cfg` file, though changing that default would be a deliberate divergence from upstream so it'd need agreeing with Google rather than being settled here -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2164943 Title: [SRU][FFE] Please update to version 20260819.00 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/2164943/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
