Hi Chloé! A few things come to mind.
> 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. Originally (going all the way back to ec2-init I guess) userdata could be supplied by the host that contained code that would run as root in the guest. But that was user-provided, unmodified by the host, and one- off at boot. Over time we've grown this property that the host can inject code into the guest at runtime to run as root at any time, and it's no longer directly done on demand by the user. When did this change happen, and in which agents? Does cloud-init have the same behaviour? Was this property present and considered in a previous security review? If it has missed consideration previously, now seems like a good time to consider it as we have to figure out what's acceptable to Ubuntu wrt. the plugin system anyway. It's also worth considering what cloud agents might do using this mechanism that we'd consider unacceptable. For example, we previously had a case where an agent was interfering with the system root of trust as provided by Mozilla[1], and that was only detected _because_ it went through our packaging process. I think that case demonstrates how our packaging processes are providing value to users and suggest that bypassing it would be counterproductive. > 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. Right. If the plugins are going to be the mechanism that new functionality will be delivered going forward, then they form essentially a complete bypass around our packaging and our processes. Ubuntu users expect the same Ubuntu everywhere, and I think that generally includes change management methods. But if they move an Ubuntu deployment to a cloud image with this package installed, something else will change behaviour outside their process. This may be exactly what they want, in which case it's fine. But it also may be exactly what they do not want, and it's up to us to strike an appropriate balance. For example, they might be implementing ITIL/ISO9001 change management requirements through package management, IaC, etc, without considering that cloud agents can bypass them depending on which cloud provider they use. Further, they might expect that an SBOM of a cloud image can be used to audit its behaviour for security vulnerabilities, but of course that would not exclude external cloud-provider-specific agent plugins that they may not know to track. If users discover these caveats after an outage or security compromise, will they they consider Ubuntu to be deficient in meeting their expectations because we allowed this bypass in our packaging? So I think there are two distinct questions of policy here: 1) on running arbitrary code on demand from the host that isn't necessarily directly requested by the user (though I accept that all clouds will of course say that they only do the user's bidding); 2) on the Ubuntu archive being "complicit" in packaging agents that run external code without actually packaging that external code. Of course hosts always[2] have control over the guests, so it's not for Ubuntu to guarantee some kind of barrier against host actions. But I think that it's a separate policy matter as to whether our packages and images should explicitly give hosts arbitrary code execution by default without user interaction. There's a separate challenge in how such user interaction can reasonably take place. Perhaps it would be sufficient to enable it through userdata, for example, and trust the host to pass that user choice through accurately and on an opt-in basis. This might be one way of resolving this dilemma. > I don't think it's mine to answer so I'd rather get the Security Team's view than just wave it through I think this is a policy question for Ubuntu and cloud images in general and not just a matter for security to consider, though of course we should rely on their assessment on the security side of things. > 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 My initial position is that correct packaging of some software that has a plugin mechanism includes packaging of the software's plugins, or else they should be unavailable by default except through explicit user action. I argue that this isn't "deliberate divergence from upstream"; it's merely correct packaging _of_ upstream. For example, you can see this with GNOME extensions in the archive already. The general principle there is that users can opt in to using external sources, but it must not be the default, and default plugins must therefore be packaged. The Technical Board has previously published this policy that is relevant to this case: https://ubuntu.com/project/docs/tech-board/3rd- party-software-sources/ I think cloud images need special consideration here. We should figure out some boundaries with the Technical Board for the cloud image case, reach an agreement on how to amend that document, and then we'll have a united understanding of how to maintain user expectations and what we need to do to achieve that. I did previously raise this general category of concern ("what should packaged cloud agents in Ubuntu be allowed to do?") with the Canonical CPC team when previously we found an agent that was interfering with the Ubuntu system certificate authority store outside upstream (Mozilla's) process. Unfortunately nobody followed up then, so we lost the opportunity to resolve this proactively. Next steps: on the "arbitrary code execution" part, I left an open question above. On both that and the "packaged agent automatically downloads external plugin and executes it" part, I think we should get a policy decision made by the Technical Board before proceeding. I think this should have been done before upload to the development release and subsequent release into Stonking, but here we are. We should certainly get this resolved before the next release. We certainly don't want to have to deal with a revert in stable releases depending on a future decision, so I don't think an SRU for this should proceed without a decision. -- [1] Problem roots of trust are quite topical right now! [2] Confidential Computing does provide an assurance against this, but that's not really relevant here since this agent functionality we're discussing would be a complete bypass of that assurance if used in a Confidential Computing environment anyway. So I hope it isn't! -- 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
