* Package name    : minijail
  Version         : 1
  Upstream Author : Jorge Lucángeli Obes <jorgelo@chromium.org>
* URL             : https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing
* License         : BSD
  Programming Lang: C, C++
  Description     : Utility to run a program inside a sandbox

minijail provides a consistent method to sandbox of services and applications,
using a mix of capability restrictions, user ID compartmentalisation, namespace
isolation and seccomp.

It is the sandboxing tool of choice for Chromium OS and Android.

 - why is this package useful/relevant?
   It's a useful security enhancement that could potentially be used by
   other packages. There's potential functionality overlap with firejail
 - how do you plan to maintain it?
   I'm open to maintaining this under collab-maint

Package: wnpp
Severity: wishlist
Owner: Yunseong Kim <ysk@kzalloc.com>

* Package name    : minijail
  Version         : 2026.05.18-1
  Upstream Author : Mike Frysinger <vapier@chromium.org>
* URL             : https://google.github.io/minijail/
* License         : BSD-3-Clause, Apache-2.0
  Programming Lang: C
  Description     : utility to run a program inside a sandbox

Minijail is a sandboxing and containment tool used in ChromeOS and Android.
It launches a program with a restricted view of the system: it can enter new
namespaces (mount, PID, network, user, IPC), pivot_root into a chosen
filesystem, drop capabilities and switch user, and apply a seccomp-bpf filter
that limits the program to a declared set of system calls.

Minijail is intended for sandboxing known binaries, to reduce the damage a
compromised service can do. It is not designed to safely run malicious code.

This takes over the RFP filed in 2017 (#860067), which has been unowned since
July 2018.

I am packaging minijail because crosvm (ITP: #1026126) requires it and cannot
enter Debian without it. crosvm's Rust bindings already prefer a
pkg-config-provided libminijail over the copy vendored in its own tree, so a
system library is all that is needed. minijail is also useful on its own as a
sandboxing tool.

The packaging is ready rather than merely intended:

  - 5 binary packages: minijail libminijail1 libminijail-dev librust-minijail-sys-dev librust-minijail-dev
  - lintian clean at -EviIL +pedantic on both the source and binary packages
  - builds from the declared Build-Depends in a clean unstable chroot
  - verified that crosvm builds and links against the resulting
    libminijail-dev, and that a kernel fuzzing workload runs through it
  - packaging repository: https://salsa.debian.org/ysk/minijail.git

The two librust-* packages need explaining, since crates normally go through
debcargo. minijail and minijail-sys are not on crates.io at all - "cargo info
minijail" cannot find them, and crosvm reaches them through a
[patch.crates-io] entry pointing at a git submodule, because ChromeOS supplies
them out of band. Their only source is rust/ in this same upstream tree, so
they are built from this source package. I am raising that on debian-rust
rather than deciding it unilaterally.

4 patches, all to be forwarded upstream to minijail@chromium.org:

  - upstream links libminijail.so with no SONAME (common.mk even carries a
    comment wondering whether to add one), which Debian Policy 8.1 requires
    for a shared library in a versioned package. The package sets
    libminijail.so.1 and tracks the ABI with a symbols file. I would rather
    upstream owned this than carry a Debian-only SONAME indefinitely.
  - minijail-sys asks for bindgen 0.63, three years old; it compiles unchanged
    against the 0.72 in Debian. The same patch drops an unused "which"
    build dependency.
  - two man page fixes: a groff warning and a typo.

I am not a Debian Developer, so I will need a sponsor for the upload.

Kind regards,
Yunseong Kim