2.3 KiB
PR#18: bwrap starts with an empty environment
WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.
Related Links
- werkdock PR#17: bwrap reads the sandbox's environment from fd 4.
- werkator PR#166: Werkator passes the values of a build's variables to werkdock through its environment.
Problem
Since werkator PR#166, werkdock's own environment holds the values of a build's variables, e.g. its secrets,
and a branch chooses some of their names.
bwrap inherits that environment, and bwrap runs on the host.
A host program that reads a variable a branch chose can be steered by the branch:
the Codex review of werkator PR#166 showed BASH_ENV reaching a credential helper of the docker client that way.
bwrap needs no variable at all, since PR#17 hands it the sandbox's environment through fd 4.
Non-Goals
- No change of what the sandbox sees.
- No change of the environment of
werkdock supervise, which is werkdock itself.
Specification
Feature: no host program reads the caller's variables
Scenario#18.01: bwrap gets nothing of werkdock's environment
… so that a variable a build chose cannot steer a program on the host.
- Given a variable in werkdock's own environment
- When werkdock starts a sandbox
- Then bwrap's environment is empty
- and the sandbox still sees its own variables
Verified by
Solution
Bwrap.Startsetscmd.Envto an empty list; bwrap needs no variable, its arguments and fd 4 carry everything.werkdock runstarts no other host program: it does not pull, andrun -dstartswerkdock supervise, which is werkdock itself. So werkdock is the only host program that reads the caller's variables, and it reads only its own names.- Red/green: without the empty list, the test finds 5,349 bytes in bwrap's
/proc/<pid>/environ. - Version 0.13.3 with a section in
CHANGELOG.md;docs/risk-analysis.mdnames the measure.
Open Questions
None.
Additional Changes
None.