| tag | a1aff6652444819a824730642e22d1b86360e9ed | |
|---|---|---|
| tagger | Jorge Lucangeli Obes <jorgelo@google.com> | Mon Jun 13 18:38:43 2022 |
| object | 3ce72e092f1ea94edc74545cd29df297e503d4fa |
Minijail v18. New in this release: * When a process encounters a seccomp policy failure, print the path to the failing policy. * Add support for a text-based configuration file. * Add support for setting and resetting the jailed process' environment.
| commit | 3ce72e092f1ea94edc74545cd29df297e503d4fa | [log] [tgz] |
|---|---|---|
| author | Jorge Lucangeli Obes <jorgelo@google.com> | Tue Jun 07 23:41:11 2022 |
| committer | Jorge Lucangeli Obes <jorgelo@google.com> | Wed Jun 08 16:48:19 2022 |
| tree | 88e0774bc587f1e0e6f2a9c69b67e0479f0a807a | |
| parent | 7e8cd81674a06111da3f1a0a90559c444bdd30df [diff] |
Always get mount flags for the source of a bind mount. mount_one was assuming that |original_mnt_flags| was always populated, even if the destination of a bind-mount existed. setup_mount_destination, on the other hand, exits early when the destination exists, assuming that if the destination exists the source flags are not needed. This is incorrect, since bind mounts are routinely used to make a filesystem object read-only only inside a specific mount namespace. In order to make something read-only using a bind mount, Minijail needs to perform two mounts: one bind-mount, and a remount with MS_RDONLY. Without knowing the flags of the original mount, the remount cannot replicate the original mount. Fix this by always obtaining the flags of the source, even if the destination exists. Do this by extracting the flag-getting functionality into a separate function. Realistically, functionality about mount flags for the *source* has nothing to do being called in a function referring to the destination. Bug: 235145151 Test: Repro in bug no longer works. Change-Id: Ia5166fdd3f36a4a01d86271e8e2dc12d6eb148ab
The Minijail homepage is https://google.github.io/minijail/.
The main source repo is https://android.googlesource.com/platform/external/minijail/.
There might be other copies floating around, but this is the official one!
Minijail is a sandboxing and containment tool used in Chrome OS and Android. It provides an executable that can be used to launch and sandbox other programs, and a library that can be used by code to sandbox itself.
You're one git clone away from happiness.
$ git clone https://android.googlesource.com/platform/external/minijail $ cd minijail
Releases are tagged as linux-vXX: https://android.googlesource.com/platform/external/minijail/+refs
See the HACKING.md document for more details.
See the RELEASE.md document for more details.
See the tools/README.md document for more details.
We've got a couple of contact points.
The following talk serves as a good introduction to Minijail and how it can be used.
The Chromium OS project has a comprehensive sandboxing document that is largely based on Minijail.
After you play with the simple examples below, you should check that out.
# id uid=0(root) gid=0(root) groups=0(root),128(pkcs11) # minijail0 -u jorgelo -g 5000 /usr/bin/id uid=72178(jorgelo) gid=5000(eng) groups=5000(eng)
# minijail0 -u jorgelo -c 3000 -- /bin/cat /proc/self/status Name: cat ... CapInh: 0000000000003000 CapPrm: 0000000000003000 CapEff: 0000000000003000 CapBnd: 0000000000003000
Q. “Why is it called minijail0?”
A. It is minijail0 because it was a rewrite of an earlier program named minijail, which was considerably less mini, and in particular had a dependency on libchrome (the Chrome OS packaged version of Chromium's //base). We needed a new name to not collide with the deprecated one.
We didn‘t want to call it minijail2 or something that would make people start using it before we were ready, and it was also concretely less since it dropped libbase, etc. Technically, we needed to be able to fork/preload with minimal extra syscall noise which was too hard with libbase at the time (onexit handlers, etc that called syscalls we didn’t want to allow). Also, Elly made a strong case that C would be the right choice for this for linking and ease of controlled surprise system call use.
https://crrev.com/c/4585/ added the original implementation.
Source: Conversations with original authors, ellyjones@ and wad@.
Minijail is manually upgraded on Chrome OS so that there is a way to test changes in the Chrome OS commit queue. Committed changes have already passed Android's presubmit checks, but the ebuild upgrade CL goes through the Chrome OS commit queue and must pass the tests before any additional changes are available for use on Chrome OS. To upgrade minijail on Chrome OS, complete the following steps.
# Sync Minijail repo cd ~/chromiumos/src/aosp/external/minijail git checkout m/main repo sync . # Set up local branch. cd ~/trunk/src/third_party/chromiumos-overlay/ repo start minijail . # replace minijail with the local branch name you want. # Run upgrade script. ~/trunk/chromite/scripts/cros_uprev --force --overlay-type public \ --packages chromeos-base/minijail:dev-rust/minijail-sys:dev-rust/minijail
At this point the Minijail-related packages should be upgraded, so you may want to add the changes to a commit and do some local testing before uploading a change list. Here are the recommended local tests to try (make sure you are not working on the minijail packages first i.e. cros_workon list-all):
# Check build. ./build_packages --board=${BOARD} # Check unit tests. FEATURES=test emerge-${BOARD} chromeos-base/minijail dev-rust/minijail-sys \ dev-rust/minijail # Check integration tests. cros deploy <DUT> chromeos-base/minijail tast run <DUT> security.Minijail.* security.MinijailSeccomp
Finally, when uploading the CL make sure to include the list of changes since the last uprev. The command to generate the list is as follows:
git log --oneline --no-merges <previous hash in ebuild file>..HEAD