You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: add gomodjail (static analysis mode) to check whether Go dependencies can reach unexpected capabilities #7410
I propose running gomodjail (https://github.com/AkihiroSuda/gomodjail) in the CI of docker/cli so that maintainers can notice dependency updates that gain unexpected privileges.
The check will run as the static analysis mode (gomodjail analyze) only; there will be no modification to the docker binary.
gomodjail also has the dynamic instrumentation mode, but it is out of this proposal at the moment.
With the static analysis mode of gomodjail, dependency modules are categorized as "confined" and "unconfined" ones.
A "confined" dependency must not be able to reach:
file read/write
network
process execution
raw syscalls
OS state modification (signals, logging, etc.)
cgo
When a confined dependency gains a path to an unexpected capability, or a new dependency is added with one, the CI will fail.
A maintainer will have to review the new dependency, and add //gomodjail:unconfined annotation to go.mod if the dependency turns out to be harmless.
The check is a best-effort static analysis: code using reflect, unsafe, assembly, etc. cannot be fully verified (reported as warnings, which do not fail the job).
Example
github.com/containerd/log v0.1.0 just wraps logrus, so it can be confined:
v0.2.0 added slog integration, and its SetFormat function now replaces the process-wide logger (slog.SetDefault, which also modifies the flags of the standard log package).
When the dependency is bumped to v0.2.0 (#7347), gomodjail fails:
This change is legitimate, so the PR should annotate the module as // gomodjail:unconfined.
The point is that the new capability becomes visible to the reviewers, rather than being buried in a large vendor/ diff.
Activity