Thanks, that makes sense. I'll drop the default-on idea. Your last point made me look closer. I see that acquire-worker.cc trusts the hashes the method reports, and only computes them itself when the method sends none. I also read #977994 and your note there about the store-method copy that failed tests.
I tried a small version of that for .debs on current main: after the method reports 201 URI Done, pkgAcqArchive::VerifyDone copies the file out of partial/ into its final place while hashing it in the main process, and accepts it only if those hashes match the expected ones. Building in a debian:sid container, the full integration suite passes with the change (334 run, 329 passed, 0 failed, 5 solver tests skipped). The only problem I hit was apt download, which downloads straight to the final name, so there is no separate file to copy from. Questions: - Do you remember what broke for you back then? - Would you welcome a merge request along these lines for .debs? And how would you want the protection itself covered by a test? I'm not sure how to make a method misbehave inside the test framework. Marc On Tuesday, October 27th, 2026 at 3:48 PM, Julian Andres Klode <[email protected]> wrote: > > > Am 27. Oktober 2026 05:36:06 MEZ schrieb [email protected]: > >Package: apt > >Version: 3.3.4 > >Severity: wishlist > > > >Hello, > > > >I would like to work on re-enabling APT's seccomp sandbox for the > >acquire methods by default, and would like to know whether the team > >would welcome that before I start. > > > >Background, as I understand it: > > > >- The sandbox was added in 2017 (32bcbd73e) and turned off by > > default in 1.6~rc1 (e688a4f48), closing LP: #1732030, #890489 and > > linuxdeploy#869. > >- The reported breakages were mostly allow-list gaps (getdents > > through NSS modules such as libnss-libvirt, socket/connect in > > store, pread64 on NFS/NIS), plus the x32 issue and environments > > where the policy cannot load. > >- The allow-list is still maintained: da74672bc (2025, #1091351) > > allowed directory reading in http for OpenSSL. > > > >Evidence that it works on common setups: > > > >- Wikimedia's puppet apt module sets APT::Sandbox::Seccomp "true" > > (operations-puppet, modules/apt/manifests/init.pp); I found no > > Allow/Trap entries anywhere in that repository. > >- Kicksecure has shipped the same setting since 2019 > > (security-misc, etc/apt/apt.conf.d/40sandbox). > >- On a current debian:sid arm64 container (2026-10-27), apt-get > > update and install --download-only hello work with it enabled, > > with no seccomp warnings. > > > >Still open: > > > >- #882588 (proxychains) and #888993 (fakeroot): LD_PRELOAD tools > > that inject syscalls a fixed allow-list cannot predict. > >- #951718: seccomp overrides by syscall number. > > > >A rough plan, one merge request per step: > > > >1. Skip the sandbox with a notice when an LD_PRELOAD wrapper is > > detected, the same way it is already skipped under qemu-user > > (243acdee1). > >2. Close the remaining known allow-list gaps and add overrides b > > number (#951718). > >3. Flip the default in unstable early in a release cycle, with a > > NEWS entry and APT::Sandbox::Seccomp "false" as the way out. > >Questions: > > > >- Would you accept a default-on change if the above is done? > >- What else, beyond the bugs above, made you turn it off in 2018 > > that I should account for? > > NSS modules fundamentally seem to make it impossible for the seccomp sandbox > to be enabled by default. > > We do also need to have clear groups of what functionality to enable. We > should not be doing this at the syscall level really. Like either we allow > file I/O or we don't for example. This reduces the risk significantly. > > >- Would you rather see Landlock for file access on top of seccom > > pacman's downloader sandbox uses both. > > A landlock branch is available. But it provides not much value if you think > about it. The downloader code runs as an unprivileged user that can only > write to that directory and more or less /tmp so what value do we get from > adding a landlock policy with the same things. > > Spending more time on these seems pointless as long as the verification of > hashes and signatures still happens within the sandbox. > > I mean it's all nice but if you can execute code you can just place a crafted > .deb there, pretend the hashes are fine and apt will go install it... > > Sadly fixing this is verrrry hard. Well debs are easy but that still leaves a > hole for indices because they can get decompressed, recompressed and you need > to have the right hashes for the final result.
