A monitoring alert kicked off my morning: runc --process /tmp/runc-process* flagged as a suspicious process. My first thought was the obvious one — something on the box is masquerading as a container runtime, spawning temp files, and hoping I’d wave it through because the name looks legitimate. That’s exactly the kind of thing an intruder does. A binary named after a runtime, a path in /tmp, a process tree I didn’t start by hand.
It was not an intruder. It was Docker doing its normal job.
What the process actually is
That path is a transient exec runtime artifact. Every time I run docker exec against a container, Docker has to get a process inside that container’s namespaces without restarting it. The way it does that is by handing a temporary spec to runc, the low-level runtime that actually creates processes. The spec is temporary by design — it exists for the duration of the exec and then it’s gone.
On my host, the monitor’s snapshot caught it mid-flight. A process that lives for a fraction of a second still shows up if the sampling interval happens to land on it, and once it’s in the alert stream it looks like a persistent threat instead of what it is: a blip with a scary name.
The tell that finally made me stop and think was the shape of the command line. It wasn’t a downloaded binary being executed from a suspicious directory. It was the runtime I already trust, invoked with a spec path in a temp location. The name was the whole reason it got flagged, and the name was the only thing the alert was actually reacting to.
Why I patched the monitor instead of the runtime
My first instinct was to suppress the alert by changing how Docker works — but that means touching container behaviour to satisfy a monitoring rule, which is backwards. The monitoring rule is wrong, not the workload. So the fix went into the detector.
I excluded precisely this pattern with grep -v. Not “ignore anything under /tmp” and not “ignore anything called runc” — those are both far too broad and would blind me to real activity in exactly the places attackers like to work. Just the transient exec artifact path, matched narrowly enough that a spec file living somewhere unusual still trips the rule.
... | grep -v 'runc --process /tmp/runc-process'The reasoning for the narrowness: a filter that’s too generous doesn’t make the monitor quieter, it makes it useless. If I suppress all of /tmp, the next alert I get from a temp path will be the one that mattered, and I’ll have already trained myself to dismiss it. Suppressing the specific artifact keeps the signal intact everywhere else.
The general lesson
Container runtime artifacts look like malware if you don’t know what they are. That’s not a flaw in either side — the runtime is operating correctly and the monitor is doing what it was told. The gap is knowledge. A process that appears briefly, runs from a temp path, and carries a privileged-sounding name is a perfectly reasonable thing to alert on if you don’t have the context to know it’s expected.
- Check the command line, not the name. The name is what triggered the alert; the arguments are what explain it.
- Lifetime matters. A process that exists for a fraction of a second and then vanishes is behaving like a transient artifact, not like a resident implant.
- Suppress narrowly. Exclude the exact artifact. Never exclude the directory, never exclude the binary name by itself.
What I took away
The alert cost me time, and the honest accounting is that most of it went into assuming the worst before reading the arguments. That’s not the wrong default for a security alert — I’d rather investigate a false positive than ignore a real one — but it does mean the useful work starts when I stop looking at the process name and start looking at the process.
The durable fix was one filter with a specific match and a clear comment explaining why it’s there. If I’d written a broad exclusion I’d have traded one noisy alert for a permanently degraded monitor, and I’d never get a reminder that the trade happened.
Related
- fail2ban Bans That Quietly Do Nothing on Docker Ports
- The Miner in ps Wasn’t Ollama, It Was a Container
- rkhunter Flagged Four Hidden Paths. All Four Were Mine
Guides & explainers
Filed under: Cybersecurity, Docker, Linux, Security Hardening