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?
- Would you rather see Landlock for file access on top of seccom
  pacman's downloader sandbox uses both.

I can test on arm64 (Docker) and on an Ubuntu 24.04 amd64 server.

Thanks,
Marc

Am 27. Oktober 2026 05:36:06 MEZ schrieb zkmarc@proton.me:

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.

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.