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

that privilege escalating syscall doesn't need to return to userland for the exploitation process to be successful.

Exactly!

Correct. Nobody is disagreeing with this. But when an exploit has happened, what else do you want to do other than to stop the malicious code as quickly as possible?