seccomp: block AF_ALG sockets#844
Conversation
mtclinton
commented
May 13, 2026
mtclinton
commented
- Block socket(AF_ALG) in the default profile, mirroring the existing AF_VSOCK deny in eaec878
- AF_ALG is the kernel crypto API interface; rarely needed inside containers; recurring CVE family (most recent CVE-2026-31431)
- JSON was regenerated via cmd/seccomp/generate.go and go test ./pkg/seccomp/... passes
- Following @Luap99's reply to a private report on security@lists.podman.io, filed publicly here.
Add a deny rule for socket(AF_ALG) to the default seccomp profile. Similar work has been done for AF_VSOCK. AF_ALG exposes the kernel crypto API (algif_aead, algif_skcipher, algif_hash, algif_rng). This is rarely needed inside containers. This closes the container attack surface for CVEs like CVE-2026-31431 ("Copy Fail"). Signed-off-by: Max Clinton <maxtclinton@gmail.com>
|
To be clear I asked for an issue to discuss but sure we can discus on PR just as well. I think blocking this is one socket family would be reasonable but overall I am not sure if this is what we want to do in general. The generic seccomp profile is not there to work around kernel CVEs. The copy fail CVE is fundamentally a bad kernel bug, blocking that for containers sounds useful first but then it does not actual protect the system outside of such container. The only way to protect the system would be to patch the kernel, or block AF_ALG system wide not just for containers and then fixing this on our profile seem not so well suited. And then there is the practical concern of us patching + releasing podman will always be slower than a kernel update. Because this is just a json file users who like this can always deploy it locally themselves. The seccomp profile denials here should be for what we consider design issues, i.e. AF_VSOCK is not namespaced so it escapes the normal container network namespace. cc @containers/podman-maintainers |
|
If we're going to do this, now is the time. This is arguably a breaking change, and our window for doing so - Podman 6 - is closing fast. I am personally in favor because we're now up to 3 exploits, all closely related, using this vector, so it seems like a pretty significant attack surface with little benefit to retaining |
Not sure I follow that thinking, if you say this needs podman 6 bc it is breaking then there is no need to patch this at all IMO. Podman 6 will not be out for most users until many weeks/months/years and by then hopefully all people patched their kernels. |
3 participants
