Build the run-phase image in CI and hold that exact image to the suites

[MarkusPaulsen]

Summary

Builds the run-phase image in CI and runs the three Landlock acceptance suites against that exact image, in an ordinary container with no security flags and no network. The claim this branch is built on stops being something a reviewer takes on trust. Repairs three things that stood in the way, including a prune image that could not build at all, and adds unit tests, coverage and a weekly drift run.

Linked issues

Stacked on #8, and targets its branch rather than main.

1. Problem

This branch's central claim is that the filesystem sandbox now works inside a stock unprivileged container. Nothing in CI built the image or ran a suite, so the claim rested on someone having run them by hand and reported the numbers.

Three defects stood in the way. The unit runner built its instrumented copy in a directory it removed on the way out, so asking for coverage and then looking for the data found nothing. The run-phase compose file pointed at a context holding no Dockerfile and no file its COPY lines match, so it could not build. And the python prune image could not build either: Ubuntu 26.04 ships a PEP 668 Python and pip3 install stops with externally-managed-environment.

The phase test also reached the network. Its probe POM named no compiler plugin version, so Maven asked for its default 3.13.0 while the image carries only 3.14.0. A registry outage could therefore have arrived looking like a sandbox regression.

2. Improvement from the user's perspective

No Improvement from the user's perspective.

3. Improvement from the maintainer's perspective

A reviewer no longer has to take the acceptance numbers on trust, or build the image by hand to check them. The suites run on every pull request against the image the same job just built, and a failure names which of the three it was.

The build context is assembled by one script that both CI and the acceptance README call. That recipe had already drifted once, when the wrapper was split into modules and the README kept listing a single .c file, and this is what stops it happening again. The script refuses a destination it did not create and clears one it did, so a stale file from an earlier context cannot be built in by a wildcard.

The mutation suite in this branch runs weekly rather than never. There is deliberately no coverage step: the unit suite interposes open and close to inject failures, which is also how gcov writes its data, so an instrumented run breaks the test asserting that a clean run says nothing. --coverage DIR still keeps the build for measuring by hand.

4. Testing manual

Prerequisites

1. A checkout of this branch and Docker. Nothing on the host has to be prepared, and no container needs --privileged, --cap-add or --security-opt.
2. gcc and python3 for the unit and coverage steps.

Steps

1. Assemble the context and build the image:
   .github/scripts/assemble-run-phase-context.sh /tmp/ctx && docker build -f docker/run_phase/java/Dockerfile -t phobos-landlock:test /tmp/ctx
2. Run each acceptance suite against it, with no network and no security flags:
   docker run --rm --network none -v "$PWD/tests/landlock-acceptance:/testsuite:ro" phobos-landlock:test bash /testsuite/run-tests.sh, then the same for extra-tests.sh and phase-test.sh.
3. Run the unit suite and keep its coverage: bash tests/unit/run.sh and then bash tests/unit/run.sh --coverage /tmp/cov.
4. Build the four prune images: for d in c java python orchestrate; do docker build -t "prune-$d" "docker/prune_phase/$d"; done.
5. Run the assembler twice into the same directory, then once into a directory you created yourself holding a file.

Expected result

1. The image builds. Before this branch the documented recipe worked, but only because it had just been repaired; the script is what keeps it working.
2. bestanden: 11, fehlgeschlagen: 0, then 15, 0, then 13, 0. All three with --network none, so nothing in them depends on a registry being reachable.
3. 134 passed, 0 failed. /tmp/cov then holds the .gcno and .gcda files, which is the point: before this branch that directory was deleted before anything could read it.
4. All four build. python is the one to watch: on this branch's parent it stops with externally-managed-environment.
5. The second run replaces the context, including removing a file you add to it between runs. The third refuses, names the directory, and leaves your file untouched.

Negative case (what must still be rejected)

The suites carry their own negative half and it is the reason they are worth running: a path outside the allow-list stays unreadable and unwritable, a write into a read-only tree is refused, and both hold for a child process and for a second JVM, as root and as a non-root user. extra-tests.sh also reads the forbidden file without the sandbox, so a denial cannot be a file permission wearing Landlock's clothes.

For this change specifically, the guard that must not be weakened is the container invocation. Adding --privileged, --cap-add or --security-opt to any of the three would make them pass while proving nothing, which is why the workflow spells all three out in a comment.

One honest limit: --network none guarantees the suites pass without a network, but it does not police the -o flags. Maven falls back to the local repository when it cannot reach a registry, so a removed -o still passes. The flag pins the property, not the spelling.

Layers exercised

• Filesystem layer
• Network layer
• Timeout layer
• All three together, as a run uses them by default

run-tests.sh exercises all three in one run: denied and permitted paths, denied and permitted endpoints, and the timeout terminating a JVM that blocks SIGTERM.

5. Test case coverage regarding this PR

Suite	Passed	Failed	Skipped	What it covers regarding this PR
tests/landlock-acceptance/run-tests.sh	11	0	0	Denied and permitted paths, denied and permitted endpoints, the timeout
tests/landlock-acceptance/extra-tests.sh	15	0	0	Inheritance by children, non-root, unenforceable policy, the control probe
tests/landlock-acceptance/phase-test.sh	13	0	0	Tightening and widening rights across phases; changed here to run offline
tests/unit/run.sh	134	0	0	The wrapper modules; changed here to keep its coverage data
tests/network_cache_ports.sh	20	0	0	The address cache, now built with the image's own hardening flags

Measured locally on ls1tum/artemis-maven-template:java17-25, kernel 7.0.12-linuxkit, arm64, and reproduced by this pull request's own Build run on ubuntu-24.04, x86-64, with the same figures. All acceptance runs use docker run --rm --network none and no --privileged, --cap-add or --security-opt.

Breaking changes and migration

docker/run_phase/java/docker-compose.yaml now expects an assembled context at build/run-phase-context and no longer names the repository root. Anyone using it must run .github/scripts/assemble-run-phase-context.sh build/run-phase-context first, which the file says in a comment. It could not build before this change, so nothing that worked stops working.

The image tag it produces changes from ajayvir/phobos to phobos-run-phase-java. No configuration file, policy key, command line or exit code changes.

Checklist

• The title of this pull request describes the change, not the implementation.
• I have self-reviewed the diff of this pull request.
• Tests were added or updated for the behaviour changed here, in both directions: the forbidden case stays denied and the permitted case still works.
• Any weakening of the sandbox boundary is stated explicitly above, including what it now permits that it did not permit before.
• The change was exercised in a container started without --privileged, --cap-add or --security-opt, or the manual says why that was not possible.
• Documentation (README.md, the comments in core/) was updated where the change is user-facing.
• CI is green, or every remaining failure is explained above.
• No secrets, tokens or absolute local paths are contained in the diff.

Review progress

• Code review
• Manual test