DirtyDecrypt, also called DirtyCBC in public reporting, reaches the vulnerable
kernel path through RxRPC/rxgk setup. This demo does not ship a local-root
exploit; it shows the required AF_RXRPC socket open without agentsh,
then closed for wrapped processes while ordinary AF_INET remains
available.
rxrpc
module. Wrapped processes see EAFNOSUPPORT for AF_RXRPC,
while ordinary IPv4 sockets continue to work.
DirtyDecrypt needs access to the RxRPC setup surface before the vulnerable
decrypt path can be exercised. agentsh blocks that setup operation directly:
the wrapped process receives EAFNOSUPPORT for AF_RXRPC,
the policy decision is written to the audit log, and unrelated socket families
remain available for normal application traffic.
This keeps the mitigation narrow. The demo is not relying on model behavior, package scanning, or a fragile command-name denylist. It denies the socket family the exploit setup needs, so any process in the supervised session receives the same deterministic result.
Docker’s default seccomp is disabled so the raw kernel surface is visible.
Alice can open socket(AF_RXRPC, SOCK_DGRAM, AF_INET), including
through a direct syscall that bypasses libc.
agentsh denies AF_RXRPC with EAFNOSUPPORT while the
control AF_INET socket stays open. The raw-syscall check proves
the block fires at the kernel boundary.
dirtyfrag-conservative mitigation includes the
AF_RXRPC boundary that DirtyDecrypt needs. It also includes the related
AF_NETLINK + NETLINK_XFRM rule. Use the explicit one-rule
config above only when you want a DirtyDecrypt-only local rule.