Hello, Falconers! Got interested in Falco and would like to contribute with your own ideas? Feeling stuck because you don't know where to start? No worries, we are here to help you! Whether you want Falco to monitor a new system call, add a brand new feature or solve a problem you ran into, you have to create a developing environment. This blog post tries to walk you through the process of setting up a new one so that you can feel comfortable and ready to start contributing! First things first, Falco's source code lives in the Falco organization on GitHub. The two repositories you should definitely take a look at are: falcosecurity/libs, containing both the kernel module and the eBPF probe, and also libscap and libsinsp falcosecurity/falco, including the rule engine, rules, and support for any kind of output, such as standard output, file output, gRPC, and more.

Capabilities To use the eBPF driver, Falco needs to be able to use the bpf syscall to load eBPF programs and create maps, and to open per-cpu ring buffers, which is done via the perf subsytem. Before kernel 5.8, the ability to perform these operations was bundled together under the CAP_SYS_ADMIN capability. To separate out BPF and perf functionalities from the overloaded CAP_SYS_ADMIN capability, the following two capabilities were introduced starting from kernel 5.8: CAP_BPF CAP_PERFMON Other important and (possibly) needed capabilities are: CAP_SYS_RESOURCE: Falco needs this to call the setrlimit syscall. This syscall is used together with RLIMIT_MEMLOCK flag. Usually, this flag is used to set the amount of memory that can be mlocked into RAM, preventing a possible swap out. On kernel <5.11, eBPF uses locked memory for maps and other things. The default memory limit value is very low, so even a very simple eBPF program will fail to load due to this. The workaround is to increase the default value to something acceptable, so that maps and other stuff can be correctly mlocked in memory. After kernel 5.11 the accounting of memory for eBPF programs and maps is done via memory cgroups, so this capability is no more needed because there is no need to change that limit. You can dig deeper reading this blog post and patch. CAP_SYS_PTRACE: Falco needs this capability because it accesses fields like environ in the proc file system, when it constucts the "state of the world" at initialization. The /proc/<pid>/environ pseudo file operations will retrieve the memory descriptor of the target process to access its memory and retrieve the environment variables. From the userspace standpoint the permission to do so is mapped to the CAP_SYS_PTRACE capability. For the curious reader, see environ_open and environ_read implementation in the kernel.