Yes, no disagreement, the policy is set to kill on escalation. The escalation happens, is detected, and the PID is killed. This is what the blog says, no? You cannot know about all vulnerabilities so you also need to prepare for the case when the escape cannot be prevented.

Looks like we have a different understanding of „privilege escalation“. IMO, spawning a shell using the process’ current credentials is not. Exploiting a kernel bug to forge higher credentials for the current process OTOH is. Your system detects the former but not the latter.

I think we have the same understanding. Tetragon detects when a process, while invoking a system call, changes namespace association, escalates privileges, or gains additional capabilities. I'm not sure why you think that is not the case.

No, it does not. Just saying it again and again doesn't make it so. Let me guide you through the exploit you were using and explain why. 🧵 1/n

The privilege escalation happens when one of the below close() syscalls exploits the previously crafted memory corruption and starts a ROP chain to raise privileges through the classic 'commit_creds(prepare_kernel_cred(NULL)).' 2/n

In particular, one of these close() syscalls will enter the kernel unprivileged and leave it with raised privileges. This destroys the claim "detects […] while invoking a system call", as it clearly does not. 3/n

Afterwards the exploit makes use of the newly gained privileges to (1) access /etc/shadow and (2) escape possible namespaces. Again, this destroys the claim of "detects when a process […] changes namespace association", as these syscalls are doing just that. 4/n

Tetragon seems to detect the exploit only later at execve() time, when it finally notices the unexpected CAP_SYS_ADMIN capability (which was effectively used already). 5/n

That's quite some syscalls after the initial privilege escalation until Tetragon reacts to it. So either it's not syscall-synchronous or too coarse grained to be effective in preventing privilege escalation. 6/6

Maybe I misunderstood how Tetragon works, but it should be able to detect earlier when the close() syscall returns. They probably just used a policy that lets the demo play out a bit