On 2025-01-31 21.11, Simon McVittie wrote:
> On Fri, 31 Jan 2025 at 19:23:07 +0000, Sean Whitton wrote:
>> On Sun 30 Jun 2024 at 11:03pm +02, Paride Legovini wrote:
>>> * I am not aware of Debian (or Ubuntu) developers actively using it.
>>> This includes autopkgtest developers, and makes the virt server not
>>> well tested.
>>
>> This statement is very surprising to me:
>> I have used it for almost every upload I have made to the archive, ever.
>
> What is your expansion of "it" here? schroot, or autopkgtest-virt-schroot?
> I think Paride was referring to a-v-schroot.
Indeed I was.
>> I was under the impression that it was such a core piece of Debian's
>> toolchain that there was no way there could be plans to remove it that I
>> wasn't even aware of.
>
> Again, what is "it" here? schroot, or autopkgtest-virt-schroot?
>
> schroot is no longer a core part of Debian's toolchain in the way that
> it was at the time of the bookworm release, because part of the response
> to the xz-utils back door (CVE-2024-3094) was a realization that schroot
> is not designed to protect the host system from malicious code running
> as root inside the chroot ("if you are root in the chroot then you are
> root in real life"). Unfortunately, running sbuild with its schroot backend
> involves running apt, dpkg and maintainer scripts from the target suite as
> root, which means that in principle, getting malicious code into unstable
> or even experimental could have been enough to achieve a root compromise on
> the buildd (and dpkg involves xz).
>
> In the case of the xz-utils back door, I believe there is consensus that
> this didn't happen, because the attacker was playing a longer game,
> wanted a back door into our stable releases, and was minimizing their
> risk of being detected early; but it could have done, and that's already
> a concern.
>
> As a result, efforts to migrate official buildds from sbuild's schroot
> backend to sbuild's unshare backend became a higher priority, especially
> for buildds that handle relatively uncontrolled suites like unstable and
> experimental. unshare runs unprivileged, so the worst-case scenario (in
> the absence of an attacker chaining several unrelated vulnerabilities)
> should hopefully be a compromise of the container or the buildd user,
> but not a root compromise of the whole machine it is running on. I
> was not involved in that effort, but my understanding is that "most"
> buildds now use the unshare backend, for this reason.
>
> I am not aware of autopkgtest-virt-schroot being a core part of Debian's
> toolchain at a distro level. ci.debian.net mostly uses a-v-lxc, with
> a-v-qemu on some architectures for some packages that benefit from the
> isolation-machine capability, and (I believe) ongoing work on supporting
> a-v-podman as an alternative to or replacement for a-v-lxc.
Great and interesting summary, thanks for writing it.
Paride
