Pre-exploit mitigation

[Ais8Ooz8]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your feature request related to a problem?

Do you intend to broaden pre-exploit mitigation efforts? Which direction do you see this going?

To quickly recap the situation: in attempting to mitigate container escapes, Tetragon tries using advanced Linux kernel features like eBPF and kprobes not to protect the very same kernel from getting exploited, but instead to stop an already successful exploit from using its gains. Going back to security fundamentals, this approach is simply infeasible: post-exploitation detection/mitigation is at the mercy of an exploit writer putting little to no effort into avoiding tripping these detection mechanisms.

Tetragon leverages bpf_send_signal() primitive to send a kill signal to the process from the kernel space itself. Using a Tetragon policy one can specify a rule that says, if a specific system call is called with certain parameters then send a kill signal to that process. As an example, if the user does not want any process to access a specific file, then one can set a rule saying, that if syscall file_open is executed with the corresponding file path, then send a kill signal to the process.

Most other systems typically employ "post-attack mitigation" that kills a process/pod after malicious intent is observed, allowing an attacker to execute code on the target environment. Essentially KubeArmor uses inline mitigation to reduce the attack surface of a pod/container/VM. KubeArmor leverages best of breed Linux Security Modules (LSMs) such as AppArmor, BPF-LSM, and SELinux (only for host protection) for inline mitigation.

Is it correct to say that the criticism of Tetragon isn't entirely accurate, since error injection is possible? You write that "only system calls and security check functions allow their return value to be changed in this manner" so does that mean some classes of exploits might still be missed? How do you view KubeArmor’s strategy?

There are two ways that Tetragon performs enforcement: overriding the return value of a function and sending a signal (e.g., SIGKILL) to the process. Override the return value of a call means that the function will never be executed and, instead, a value (typically an error) will be returned to the caller. Generally speaking, only system calls and security check functions allow to change their return value in this manner.

Describe the feature you would like

Implementation of pre-exploit mitigation for all classes of exploits

Describe your proposed solution

No response

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[mtardy]

Hey, yeah things have changed since the blogpost by grsecurity was written (3/4 years ago now), iirc the post was mostly complaining about wording in one of our blogpost.

Is it correct to say that the criticism of Tetragon isn't entirely accurate, since error injection is possible?

Indeed, I didn't know this blogpost by AccuKnow but it seems they haven't investigated enough, so from a feature PoV, the comparison seems unfair.

You write that "only system calls and security check functions allow their return value to be changed in this manner" so does that mean some classes of exploits might still be missed?

It just limits how you can write the TracingPolicy, but this is a Linux limitation (not a Tetragon one), because you wouldn't change the return value of any function in the kernel (it would quickly crash your system). We support also LSM security hooks now directly instead of using kprobes + security hooks.

How do you view KubeArmor’s strategy?

I don't really know much about KubeArmor unfortunately so I'd avoid making comments to not make mistakes.

Also, for this kind of discussion, the Slack channel or the community meetings might be more suited than a GitHub issue.

[Ais8Ooz8]

@mtardy BTW, how effective is Tetragon for Network Observability? Does it significantly impact resource consumption? What are its weaknesses? I've heard the opinion that this isn't practical, as there are too many events. It makes more sense to intercept security_socket_create or inet_csk_listen_start, i.e., just some of the network events. Should it be used in conjunction with Cilium?

[mtardy]

@mtardy BTW, how effective is Tetragon for Network Observability? Does it significantly impact resource consumption? What are its weaknesses? I've heard the opinion that this isn't practical, as there are too many events. It makes more sense to intercept security_socket_create or inet_csk_listen_start, i.e., just some of the network events. Should it be used in conjunction with Cilium?

You can use in conjunction with Cilium but it doesn't provide any particular benefit. Tetragon can run standalone.

Now for network, you need to find the strategy that suits you indeed because you can provide a lot of events, we provide a few policies from the docs and examples.