External/pmg
1
0
Fork 0
mirror of https://github.com/safedep/pmg.git synced 2026-08-03 07:24:09 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: correct the container CA instructions, they did not work

Browse Source 
The mount command in the Docker section was written from reasoning and
never run. Testing it showed it fails.

Mounting the bundle over /etc/ssl/certs/ca-certificates.crt lands
correctly, and the file contains the right CA, but curlimages/curl does
not read that path by default and still fails with exit 60. The runtime
has to be pointed at the file explicitly.

Verified commands now in the doc:

  NODE_EXTRA_CA_CERTS=/ca.pem   node:20-slim        npm i is-odd -> added 2 packages
  NODE_EXTRA_CA_CERTS=/ca.pem   node:20-slim        safedep-test-pkg -> code E403
  CURL_CA_BUNDLE=/ca.pem        curlimages/curl     http=200

So PMG does block a malicious package inside a container once the
certificate is passed in. SSL_CERT_FILE was also tried and does not work
for curl, so it is not documented.

Also notes that the docker commands need an account with sudo, since
testuser deliberately has none.
This commit is contained in:
Sahilb315
2026-07-28 23:05:31 +05:30
parent 0deb8fa4ff
commit a814bf648e
2 changed files with 52 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design/linux-ebpf-enforcement.md
+13 -5
View File
@@ -529,11 +529,19 @@ Do not bind `0.0.0.0`. The state file would record `0.0.0.0`, which is not a val
properly needs `bpf_get_netns_cookie()` in the hook to select a target per namespace.
- **A non loopback bind exposes the MITM proxy.** Acceptable on an isolated runner, otherwise it
needs a firewall rule.
- **CA trust inside the container is unsolved and may be unsolvable from the host.** A container has
its own trust store, and nothing on the host reaches into it. Injecting the CA requires the
process that starts the container to mount it. So for containers the guarantee degrades to fail
closed: traffic is mediated, the install fails, nothing unanalysed enters. That is the correct
security outcome and a poor usability one.
- **CA trust inside the container cannot be arranged from the host.** A container has its own trust
store and nothing on the host reaches into it. With the certificate mounted and the runtime told
to read it, the full flow works: `npm i is-odd` succeeded inside `node:20-slim` and
`safedep-test-pkg` was blocked with 403. But that requires the process starting the container to
cooperate, which is the assumption the whole layer exists to remove. Without it the guarantee
degrades to fail closed: traffic is mediated, the install fails, nothing unanalysed enters. That
is the correct security outcome and a poor usability one.
Mounting over the image's CA bundle path is not sufficient on its own. Tested against
`curlimages/curl`: the mount lands and the file is correct, but curl does not read
`/etc/ssl/certs/ca-certificates.crt` by default and still fails. The runtime has to be pointed at
the file explicitly, through `NODE_EXTRA_CA_CERTS`, `CURL_CA_BUNDLE` or `--cacert`. Per runtime
again, which is the same shape as the host side problem.
Note `docker pull` was already covered before any of this, since the daemon runs on the host.