* 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
Dear Yunseong, I'm also interested in packaging crosvm in Debian. As it is the last piece to run android-cuttlefish purely within Debian. If you still need a sponsor, I can try to sponsor minijail for you because it is a build dependency of crosvm. But I'm not sure if you already have a sponsor. I am just another DD so I can sponsor it for you if you want. Can we work together to get crosvm into Debian? Yours, Paul
Hi Paul, Thank you for your encouragement. Yes, I also needed crosvm, a Rust-written VMM as an alternative to QEMU, for my own security research, and I believe it can be valuable to others as well. My recent upload #4 minijail on here: https://mentors.debian.net/package/minijail/ Salsa CI for minijail pipeline also passed: https://salsa.debian.org/ysk/minijail/-/pipelines/?pow_referer= Yes, your idea is really great! I hope so too. Currently, My crosvm ITP describe my plan: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026126#56 I would like to ask about the next steps for making progress on packaging minijail. Thanks! Best regards, Yunseong
Hi Yunseong, I tried to review the minijail package. I mean from https://salsa.debian.org/ysk/minijail.git The git repo layout is a bit weird. Both upstream-branch and debian-branch are set to debian/latest. I'm not sure if this is a good practice. I'm not sure because I didn't see this setting before. I know we have to build minijail from the upstream's git version because the upstream might not have a good release. Same as crosvm, we might need to do the same. But when we use uscan (debian/watch), it should create an orig.tar.gz automatically. And thus we can gbp import-orig with --uscan to import it into the upstream-branch. And I also see that you turn off the pristine-tar. I'm not sure if this is a good idea because if other people use "gbp clone" to download your source package. Without pristine-tar, if he uses "gbp export-orig" to recreate the source tarball, he might get a different tarball. For example, if I use "gbp export-orig" I will get c38e8df802e84bd6af9ad54301e6e1d1 minijail_2026.05.18+git20260817.8d20993.orig.tar.gz But on mentors yours is d00d802ff7e7ed8f0d4685c959362525 minijail_2026.05.18+git20260817.8d20993.orig.tar.gz. This is because without pristine-tar, each time you run "gbp export-orig", it will re-compress the content. And thus it will be different sometimes. Pristine-tar is the tool to keep the original source tarball always the same on upstream versions. So I would suggest the gbp.conf be pristine-tar = True debian-branch = debian/latest upstream-branch = upstream/latest And you might want to use uscan to create an init tarball. And use gbp import-orig to re-create a clean git repo. If you need help I can do this for you. And I'll show you how to maintain this git repo by gbp and write it into README.source. Yours, Paul
Hi Yunseong, Salsa is broken now. At least mine is broken. So actually I don't mind if we really want to use gbp or not. If you want, we can do it the traditional way. I mean I'll just review the .dsc .debian.tar.xz and .orig.tar.gz. And you can just remove those Vcs-Browser: and Vcs-Git: fields in debian/control. So we just dget and dput for development. I know some people might feel bad about this but salsa is sometimes not working. And minijail is just a build dependencies of crosvm. So I expect that there won't be a many-people team co-maintain this. Crosvm might need to use gbp and salsa because it is larger. But minijail I think it is ok to just do the traditional way. Yours, Paul
Hi Yunseong, How's it going? I've re-created the git repo through "gbp import-dsc --pristine-tar --debian-branch=debian/latest --upstream-branch=upstream/latest minijail_2026.05.18+git20260817.8d20993-1.dsc" by your uploads to mentors. And then I modified the debian/gbp.conf to reflect the changes. I've pushed it to https://salsa.debian.org/paulliu/minijail If possible please take it over or you can do the same commands so that the git repo layout can be the same as others. Don't hesitate to ask me anything to make things go further. Yours, Paul
Hi Paul, Thank you for recreating the repository and explaining the layout! Sorry for the delayed reply. I was in Prag for OSS Summit. I've applied: 1. your gbp.conf changes patch to my repository, 2. rebased the packaging onto upstream latest snapshot 8787d1a, 3. and recorded the new tarball in pristine-tar. Tarball verification, the package build, and signing all completed successfully. Please let me know if there’s anything in my changes that I should double-check. The updated branches and upstream tag are now on my Salsa repository. I've also uploaded the new source package, version 2026.05.18+git20261016.8787d1a-1, to mentors for review. https://mentors.debian.net/debian/pool/main/m/minijail/minijail_2026.05.18+git20261016.8787d1a-1.dsc Thanks again for your guidance! Best regards, Yunseong
Hi Yunseong, I've uploaded it to the new queue. Let's wait for ftp-master to review. Yours, Paul
We believe that the bug you reported is fixed in the latest version of
minijail, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 860067@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Yunseong Kim <ysk@kzalloc.com> (supplier of updated minijail package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 24 Aug 2026 16:50:00 +0200
Source: minijail
Binary: libminijail-dev libminijail1 libminijail1-dbgsym minijail minijail-dbgsym
Architecture: source amd64
Version: 2026.05.18+git20261016.8787d1a-1
Distribution: unstable
Urgency: medium
Maintainer: Yunseong Kim <ysk@kzalloc.com>
Changed-By: Yunseong Kim <ysk@kzalloc.com>
Description:
libminijail-dev - sandboxing and containment library - development files
libminijail1 - sandboxing and containment library
minijail - utility to run a program inside a sandbox
Closes: 860067
Changes:
minijail (2026.05.18+git20261016.8787d1a-1) unstable; urgency=medium
.
* Initial release. (Closes: #860067)
* Package upstream Git snapshot 8787d1a.
* Update debian/gbp.conf to use separate Debian and upstream branches
and enable pristine-tar.
Checksums-Sha1:
e1ab4e88e3bc68eb60ec0640373d22e6c7215d7e 2153 minijail_2026.05.18+git20261016.8787d1a-1.dsc
02a7c8dadab24a051be4fe143cb8f0d4a11d8561 253163 minijail_2026.05.18+git20261016.8787d1a.orig.tar.gz
2aa9574237852cbe57bc29719ebd12b280651c27 6092 minijail_2026.05.18+git20261016.8787d1a-1.debian.tar.xz
87336f4ea7f4b1c1b7970a2bddd6c9f15a97e4cc 9784 libminijail-dev_2026.05.18+git20261016.8787d1a-1_amd64.deb
69c3c277f571cca7ad9b33a5edeab96bded3b87b 211828 libminijail1-dbgsym_2026.05.18+git20261016.8787d1a-1_amd64.deb
5fae1aed29fa08e48beb0362c808c25e91bc4190 63144 libminijail1_2026.05.18+git20261016.8787d1a-1_amd64.deb
1e775ba5ff65f7b5710f93952cfaaca53b5d9499 389068 minijail-dbgsym_2026.05.18+git20261016.8787d1a-1_amd64.deb
91272732ad532c9c24e78acc796fec957e8b36d6 7356 minijail_2026.05.18+git20261016.8787d1a-1_amd64.buildinfo
b6b29a641359cf486f1470d7718d549ff16410b0 104836 minijail_2026.05.18+git20261016.8787d1a-1_amd64.deb
Checksums-Sha256:
bd3d9d68333287fdd714cb4410bb305ee3488a06969b23eea987a0c7e3b64b4e 2153 minijail_2026.05.18+git20261016.8787d1a-1.dsc
0209030afadd481703e4370caf0498801a9cdb63a92e84524073c72850f03ef5 253163 minijail_2026.05.18+git20261016.8787d1a.orig.tar.gz
ae6ae2480b6e996e2628400fa083cb6f62ca5c12febd043c5fcaad9d4a534a5b 6092 minijail_2026.05.18+git20261016.8787d1a-1.debian.tar.xz
e1585cb978ffc1fbc4ca167e59caf31fd1db9ec0a27997a888f90e3427abdfb5 9784 libminijail-dev_2026.05.18+git20261016.8787d1a-1_amd64.deb
de979ebf425843bdcd5ba1f32dc580312b7366778f5e09adf146f73d651eb236 211828 libminijail1-dbgsym_2026.05.18+git20261016.8787d1a-1_amd64.deb
984a16e70a19d217aa7eb094bc0ad7cf8041c99bd3421c22d97325cda0fe729b 63144 libminijail1_2026.05.18+git20261016.8787d1a-1_amd64.deb
57740466a3566369964818b504b305b9178a27bd44e3fcc5f6d787b4306a2b20 389068 minijail-dbgsym_2026.05.18+git20261016.8787d1a-1_amd64.deb
cb40e511a1b4e49adb49a87092ac9946dc60a7caf68f67d6e5e5ab34a151b8d7 7356 minijail_2026.05.18+git20261016.8787d1a-1_amd64.buildinfo
7a8c9732c5ef990ea16bfc8b15101ef6585b95300a7552657918d3cdaab1e82d 104836 minijail_2026.05.18+git20261016.8787d1a-1_amd64.deb
Files:
c31b001ec3e87660cba903cd4a9c66c7 2153 admin optional minijail_2026.05.18+git20261016.8787d1a-1.dsc
88ea7b52e71e22fd4bb8fe5418243379 253163 admin optional minijail_2026.05.18+git20261016.8787d1a.orig.tar.gz
ff5c0379415e7fb54e3f32b31e4cb077 6092 admin optional minijail_2026.05.18+git20261016.8787d1a-1.debian.tar.xz
4920da4177cdc3886dc51367c7bd41dd 9784 libdevel optional libminijail-dev_2026.05.18+git20261016.8787d1a-1_amd64.deb
321eacd9cc307338472c0d569ea00d66 211828 debug optional libminijail1-dbgsym_2026.05.18+git20261016.8787d1a-1_amd64.deb
28fe4850b34b34e79417eaf626aa6a80 63144 libs optional libminijail1_2026.05.18+git20261016.8787d1a-1_amd64.deb
828442e85632baa94cfc3a26c5e8080c 389068 debug optional minijail-dbgsym_2026.05.18+git20261016.8787d1a-1_amd64.deb
82dcbfadc112383e2e40efc15fa95c67 7356 admin optional minijail_2026.05.18+git20261016.8787d1a-1_amd64.buildinfo
bfad4c6d3abc4cdc1f46c60e014b8aac 104836 admin optional minijail_2026.05.18+git20261016.8787d1a-1_amd64.deb
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEo2h49GQQhoFgDLZIRBc/oT0FiIgFAmrWPxcACgkQRBc/oT0F
iIjlgg/9FxTKdrFHPFO5hne1lQIMvOG49qoIffFtnoloTpIPZQibnX5Clkj6nt8I
OGUduTvrXKpxFqpgr6nFBxYouF0VygEOaAjjZvoXJUDbCbeJh7Pykn0T6aEfu0jA
q4wzwIrZW43rK75tgYXamYulOJDWk74tHZ0V5kueSMqwC11lzk6Mk2dtxK8a++ef
9QdBrGgmxBSOcMifNeW++dieWjQKBURgQAaVKQE/ywvR+9itbk+O+bPNHGtiYV3U
thwEhpsGW0Tp89glEoIx9JzmdGF0GunGdgt0QL7IIcK/+0yPmpuRKHpkD9hKMUOu
ufUAuBlkRUyNFEGZDkGK/7l33LLMP3DUQRmqZTu/5mwlhD46tHIetE7U53CqjjST
6efN4visBzy77tbws/sv729RalzUX6FE0U+KfMhPtvs4hCp5oHYqBtxBjegLqOOD
NY6M5oPtObtgitdbaDvLav194pPk8YSunuS9x9Mv++mk265Z3hJWcW7gidU/7Vk5
H9zIHobq5/HH4KWXe5+SeP4Of9RXGxZa2xRrmNcWjhKrN27CPp+2xhmn8bs9D7Yh
nW2AGSKVRg0Q6xV9V6na8rE6e/Xk6CRDXJ4PCRKyI7pPMVoa9sza8w4w/8QHFj5/
l2I+3zA8N9OgYiH6h9SA3mXrBvOC6wWkd/ddKW2cl/mYebW32l8=
=glVR
-----END PGP SIGNATURE-----
Hi Paul,
Thank you again for sponsoring minijail. Version
2026.05.18+git20261016.8787d1a-1 (below just "-1") has been accepted
into unstable.
While packaging crosvm (ITP #1026126), I found that -1 does not include
three things crosvm needs at build time. Upstream crosvm takes them from
its third_party/minijail git submodule, which is empty in a Debian orig
tarball. So I have prepared the next Debian revision,
2026.05.18+git20261016.8787d1a-2 ("-2"), with the same upstream source
and three new binary packages:
- librust-minijail-sys-dev: rust/minijail-sys, the bindgen FFI crate
- librust-minijail-dev: rust/minijail, the safe wrapper crate
- python3-minijail: compile_seccomp_policy and the other policy
tools from upstream's setup.py; crosvm's
jail/build.rs runs compile_seccomp_policy
to compile its seccomp policies
The packaging is on Salsa:
https://salsa.debian.org/ysk/minijail (branch debian/latest, a5d30d3)
Hi Yunseong, I think you can just upload -2 to mentors. And you don't need to file an RFS bug because I will sponsor your uploads anyway. Just send me the dsc link on mentors and I'll do it for you. BTW, I know that minijail is not published to crates.io. And it is totally ok for me. I mean there's not only one way to package rust packages. Some people choose not to use the Rust team tools and package things by themselves from scratch. I know it is ok for things even in crates.io. And in our cases, it is not in crates.io and thus we have more reasons to do things our own way. So the way you handle the rust crates looks good to me. Yours, Paul
Hi Paul, Thank you for the reply, and for being fine with how the Rust crates are packaged. I uploaded -2 to mentors: https://mentors.debian.net/debian/pool/main/m/minijail/minijail_2026.05.18+git20261016.8787d1a-2.dsc It matches the Salsa branch: https://salsa.debian.org/ysk/minijail (branch debian/latest, 88935a4) One change since my previous mail: the debcargo-style Provides of the two librust packages are now versioned with the crate versions, e.g. librust-minijail-sys-0.0+default-dev (= 0.0.14) and librust-minijail-0.2+default-dev (= 0.2.3), rather than with the minijail package version. Otherwise an upper-bounded dependency on them (such as "<< 0.0.15~~") could never be satisfied. I rebuilt that exact .dsc in a clean unstable chroot (amd64 and arch:all): lintian reports no errors or warnings, both autopkgtests pass, and crosvm builds against the resulting packages. The upload is source-only and includes the orig tarball, which is the same file as in the archive (sha256 0209030a...). Since -2 adds new binary packages it goes through NEW, so it will need a binary upload from your side. Once it is accepted, I will prepare a source-only -3 for testing migration, unless you would rather do that differently. I have not tagged -2 yet. I can tag debian/2026.05.18+git20261016.8787d1a-2 on 88935a4 after the upload, or you can tag it when you upload, whichever you prefer. Thanks again! Yunseong Kim