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.
