kevsecurity
commented
9 months ago Hello
Rate limiting is per thread and your test involves starting numerous 'cat' processes one after the other, each with a different thread ID. As such, no rate limiting occurs. The idea is to limit a single thread's repeated events, not repeated events generally.
I turned the rateLimit value in the policy down to 3s for testing, and used the following C program to generate tests:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char *argv[])
{
int fd;
int count = 1;
char buf[65536];
struct stat st;
while (1) {
fd = open("/etc/passwd", O_RDONLY);
if (fd < 0) {
printf("open failed: %s\n", strerror(errno));
exit(1);
}
if (fstat(fd, &st) < 0) {
printf("fstat failed: %s\n", strerror(errno));
exit(1);
}
if (read(fd, buf, st.st_size) <= 0) {
printf("read failed: %s\n", strerror(errno));
exit(1);
}
printf("Opened /etc/passwd: %7d\n", count);
count++;
close(fd);
sleep(1);
}
return 0;
}It wouldn't be difficult to add a switch to the rate limiting function to make it apply to all threads. Let me know if that would be helpful.
vladimirkus
kkourt
What happened?
Applied rateLimit according to the documentation. Here is the whole tracing policy:
As far as I understood from the documentation this may significantly decrease count of repetitive events, however this didn't have any noticeable effect.
During the experiment I generated events with
while true; do cat /etc/passwd > /dev/null; done.Are there any constraints using rate limiting, or probably I misunderstood the concept?
Tetragon Version
1.0.1
Kernel Version
5.15
Kubernetes Version
1.24
Bugtool
No response
Relevant log output
No response
Anything else?
No response