v0.29.1

A security release. If ofelia watches a Docker host that also runs containers you do not fully trust, upgrade to this version.

Upgrade now if you run ofelia in Docker-label mode

Jobs can be defined by the labels on the containers ofelia scans, so a container could set labels on itself to have a job run against it. Three privilege-bearing keys on those jobs were honored no matter where they came from — even with allow-host-jobs-from-labels in its default, off state, the setting that is supposed to keep host jobs out of labels entirely.

• privileged on a job-exec reached docker exec --privileged, the starting point for a privileged-container escape to the host.
• env-file read a file from ofelia's own filesystem view into the job's environment — its mounts, its injected config, any credential file it can see.
• env-from copied another container's entire environment, secrets included, into a job the attacker controls.

The label-security filter added for host bind mounts covered job-run / job-service-run but never these three keys, and job-exec was not routed through it at all. This release strips privileged, env-file and env-from from every label-defined job unless you have explicitly set allow-host-jobs-from-labels=true — on both first sync and every later container reconcile — and logs a SECURITY POLICY VIOLATION each time it does. Keys are stripped in place, so the job still runs, just unprivileged and without host or cross-container environment. Configuration from an INI file is trusted and unaffected, and setting the opt-in flag restores the old behaviour for single-tenant hosts.

Reported by @KamilPesek and fixed by @CybotTM. Affected versions, CVSS and the full write-up are in GHSA-h7m7-v83x-vfp3.

Security

• Label-sourced jobs can no longer carry privileged, env-file or env-from past the host-escalation policy. Stripped from every label-defined job unless allow-host-jobs-from-labels=true, on both the initial-load and live-reconcile paths, matched by normalized key so casing and separator variants are caught, logged per stripped key (#791, GHSA-h7m7-v83x-vfp3).

Full changelog: v0.29.0...v0.29.1

Container image

ghcr.io/netresearch/ofelia:0.29.1
ghcr.io/netresearch/ofelia:0.29
ghcr.io/netresearch/ofelia:0

Verify your download

Per-asset signatures are bundled. Verify any single file:

cosign verify-blob \
  --bundle ofelia-linux-amd64.sigstore.json \
  --certificate-identity-regexp "^https://github\.com/netresearch/\.github/\.github/workflows/release-go-app\.yml@" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ofelia-linux-amd64

Verify checksums against the signed manifest:

cosign verify-blob \
  --bundle checksums.txt.sigstore.json \
  --certificate-identity-regexp "^https://github\.com/netresearch/\.github/\.github/workflows/release-go-app\.yml@" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  checksums.txt
sha256sum -c checksums.txt --ignore-missing

Verify build provenance. Releases are built by a reusable
workflow, so the signing identity is that workflow rather than
this repository -- --signer-workflow is required and
verification fails without it:

gh attestation verify <artifact> \
  --repo netresearch/ofelia \
  --signer-workflow netresearch/.github/.github/workflows/release-go-app.yml

Verify container image:

cosign verify ghcr.io/netresearch/ofelia:0.29.1 \
  --certificate-identity-regexp "^https://github\.com/netresearch/\.github/\.github/workflows/release-go-app\.yml@" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"
gh attestation verify oci://ghcr.io/netresearch/ofelia:0.29.1 \
  --repo netresearch/ofelia \
  --signer-workflow netresearch/.github/.github/workflows/release-go-app.yml