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.
> 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.
Incidentally, I suspect that a-v-lxc should also be considered "at risk",
because my understanding is that it's based on an old version of the
lxc interface, whose upstream developers consider it to be deprecated
and would variously recommend replacing it with either lxd or Incus,
depending on who you ask.
(I have not attempted to carry out a security audit on any of these
container managers, and I am not a professional exploit developer; all
of this is merely to the best of my limited understanding.)
I am sorry that I do not have the spoons to support every container
technology, past and present, at an equivalent level, and I am sorry that
my attempts to re-scope my maintainer responsibilities by supporting fewer
container managers fail to meet your expectations.
smcv
