poiana
commented
1 year ago There is not a label identifying the kind of this issue.
Please specify it either using /kind <group> or manually from the side menu.
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
LucaGuerra
tspearconquest
FedeDP
Andreagit97
As we know we have three main avenues install the system instrumentation to get live syscall info into Falco:
The first two are the most compatible but require building the drivers or downloading a prebuilt for your kernel. While we have thousands of prebuilts it is sometimes necessary to build your own driver. If you're using a container-based install, this is what the falco-driver-loader image attempts to do.
That image has a noble purpose, to try and build the driver for the live system it is on provided that kernel headers are present, but it's not without issues. For historical reasons, a ton of old compilers are still installed in a relatively old image (Debian Buster) to retain compatibility with older kernels (3.x and below). However, that image is unable to build the driver for newer versions (kernel > 5.0 and perhaps some 4.xx as well). In addition, if you try to run the image through a SCA / vulnerability scanner tool it will alert about maybe hundreds of vulnerabilities which are present in very old compilers and accompanying libs that are necessary for older distributions; for all practical security purposes those are all false positives but they would show up flashing on a security status dashboard and would make compliance experts feel uneasy.
The sad fact is that it's not even possible to build an image that works for everyone. In fact, even driverkit has resorted to using several different images to to this job.
This led me to try and look into the compiler versions we actually use when creating our prebuilt and trying to understand if we want to upgrade the default driver loader image. To learn which compilers we may want to put there I ran a little experiment: took all the current driverkit configs we use and looked at all the image selections. The results are as follows (after removing duplicate kernel versions):
Basically, we use the gcc 11-12 image most of the times. In fact, as a rule of thumb, we use the gcc11-12 image for 5.x and 6.x while we use the old image for 4.x and below. So, we're recently picking up many variations of kernel 5.x because it seems like it's the most widely supported at the moment (Ubuntu, Amazon Linux, some recent RHEL and CentOS...) while 4.x versions are not seeing many updates.
I believe it may be time to upgrade the base image to something like this: https://github.com/falcosecurity/driverkit/blob/master/docker/builders/builder-any-x86_64_gcc12.0.0_gcc11.0.0.Dockerfile since building on 5.x and 6.x seems to be becoming more important than the previous versions. If we could also add another gcc version that is compatible with some 4.x I believe it would work even better.
This issue acts as a place of discussion about what we want to do. There may be more ideas, and even more things we want to do for people that cannot use this base image, but I did want to open this discussion.
/kind design