Falco – Gsoc

Blog: Halfway Through GSoC 2024: My Progress and Plans with Falco

Wed, 24 Jul 2024 00:00:00 +0000

Hello Falco community, I'm Kiriti, a current GSoC mentee under Falco Security. I have been working diligently to improve the testing and benchmarking capabilities of Falco’s event-generator project. Now that we've reached the midterm of GSoC, I'm eager to share the journey so far. In this blog, I'll delve into the details of my contributions, particularly focusing on two key PRs that have been merged, and outline my plans for the remainder of the program.

My Project: Enhancing Falco's Event-Generator

The event-generator is a vital utility within the Falco ecosystem, designed to test Falco's detection capabilities. My Google Summer of Code project focuses on upgrading the event-generator to enhance its testing and benchmarking capabilities, reliability, and consistency. Additionally, I am developing new Continuous Integration (CI) pipelines based on the upgraded event-generator. The ultimate goal is to evolve the event-generator into the standard tool for systematically assessing the correctness and performance of Falco’s threat detection capabilities during every release and development cycle.

My Journey So Far:

Before being selected for GSoC, I contributed to the event-generator repository. I am grateful to Leonardo Grasso and Federico Di Pierro, who played a vital role in getting my PRs merged during the pre-GSoC contribution phase. These contributions helped me understand the event-generator codebase. I am also thankful to my mentors, Jason Dellaluce and Aldo Lacuku, for selecting me as a GSoC mentee. I will share my complete story of getting selected to GSoC in future.

After my selection, Jason, Aldo, and I collectively designed a plan to enhance the event-generator. The community bonding period was crucial in designing and understanding the implementation plan. You can view our idea here, which we will implement during this GSoC period.

Once the coding period began, we managed to merge two key PRs before the midterm. These PRs partially added support for testing Falco rules using declarative YAML files in the event-generator. We also added support for a container runner, which spawns a new container and runs the specified steps inside it. This is particularly useful for testing Falco rules that trigger when certain events are executed inside a container.

Detailed Look at the Merged PRs:

PR1: Add support for declarative yaml file testing
- what's new added in this PR?:
  - Added a new sub command for run command called declarative:
```
event-generator run declarative [yaml-file-path]
```
  - Implemented a helper function that parses the YAML file and returns the content in a specified format. The function signature is as follows:
```
 func parseYamlFile(filepath string) (declarative.Tests, error)
```
    Each yaml file structure should be in the following format
```
 type SyscallStep struct {
 Syscall string `yaml:"syscall"`
 Args map[string]string `yaml:"args"`
 }

 type Test struct {
 Rule string `yaml:"rule"`
 Runner string `yaml:"runner"`
 Before string `yaml:"before"`
 Steps []SyscallStep `yaml:"steps"`
 After string `yaml:"after"`
 }

 type Tests struct {
 Tests []Test `yaml:"tests"`
 }
```
  - Implemented a host runner A host runner is represented with the following interface
```
 type Runner interface {
 Setup(beforeScript string) error
 ExecuteStep(step SyscallStep) error
 Cleanup(afterScript string) error
 }
```
    The Setup method runs a shell script (beforeScript) before executing the specified steps using the ExecuteStep method. The Cleanup method runs a shell script (afterScript) after executing the steps.
    
    The ExecuteStep method makes some syscalls specified in the YAML file using helper functions. For example, when a write syscall is used in the YAML file steps, it runs the following write syscall helper function:
  - Added helper for making a write syscall: The function signature is as follows
```
 func WriteSyscall(filePath string, content string) error
```
PR2: Add container runner support
- To implement a container runner, we needed the ability to spawn a container and execute the events inside it. We achieved this using the Docker GO SDK.
- The container runner interface is similar to the host runner, with two new parameters: ContainerId and Image.
- The Setup method spawns a container with the given image name, saves the ContainerId, and also executes the beforeScript. The Cleanup method removes the container after executing the steps.
```
 type Runner interface {
 ContainerId string
 Image string
 Setup(beforeScript string) error
 ExecuteStep(step SyscallStep) error
 Cleanup(afterScript string) error
 }
```

Future Work:

The upcoming tasks we are going to handle are:

Implement ExecuteStep method in container runner
Add support/ helper functions to make various syscalls
Improve benchmarking capabilities of the event-generator
Integrate the event-generator in falco ci pipeline

Conclusion:

Participating in GSoC with Falco Security has been an incredible journey so far. Enhancing the event-generator has provided me with invaluable insights into cloud-native runtime security and the complexities of Falco’s detection capabilities. The support and guidance from my mentors, Jason and Aldo, through our weekly 1:1 calls, have been crucial in overcoming challenges and driving the project forward.

As I look ahead, I am excited about the upcoming tasks and the potential impact our improvements will have on the Falco ecosystem. I eagerly anticipate continuing this journey and sharing more updates on our progress. Thank you for following along!

Blog: Gsoc Week-3 and Week-4 updates

Tue, 18 Jul 2023 00:00:00 +0000

This week I worked on creating parsers for the syscalls that I added previously. I learnt how metadata is extracted from the syscalls to provied user with more context on the triggred syscall. We also compiled Falco's main repository from which the web application will be built on. As always, thanks to my mentor Jason Dellaluce for assisting me!

Wasm Target For Falco 🦅

Now that Libs has wasm support, it's time for Falco to get it's new target as well.

Similar approch to libs was followed here as well. We first modified cmakelist to add the wasm target and added the preprossesor checks for emscripten. Finally we added CI to build and test wasm target for flaco.

More information about this, here.

A quick run of falco --help command through node.js 🤩

root@rohithraju:~/code/falco/build_emcc# node ./userspace/falco/falco.js --help
Falco - Cloud Native Runtime Security
Usage:
falco [OPTION...]
-h, --help Print this page
-c <path> Configuration file. If not specified uses /etc/falco/falco.yaml.
-A Monitor all events supported by Falco defined in rules and configs. Please use the -i option to list the
events ignored by default without -A. This option affects live captures only. Setting -A can impact
performance.
-b, --print-base64 Print data buffers in base64. This is useful for encoding binary data that needs to be used over media
designed to consume this format.
--cri <path> Path to CRI socket for container metadata. Use the specified socket to fetch data from a CRI-compatible
runtime. If not specified, uses the libs default. This option can be passed multiple times to specify
socket to be tried until a successful one is found.
-d, --daemon Run as a daemon.
--disable-cri-async Disable asynchronous CRI metadata fetching. This is useful to let the input event wait for the container
metadata fetch to finish before moving forward. Async fetching, in some environments leads to empty fields
for container metadata when the fetch is not fast enough to be completed asynchronously. This can have a
performance penalty on your environment depending on the number of containers and the frequency at which
they are created/started/stopped.
--disable-source <event_source>
Disable a specific event source. By default, all loaded sources get enabled. Available sources are
'syscall' and all sources defined by loaded plugins supporting the event sourcing capability. This option
can be passed multiple times. This has no offect when reading events from a trace file. Can not disable all
event sources. Can not be mixed with --enable-source.
--dry-run Run Falco without proceesing events. Can be useful for checking that the configuration and rules do not
have any errors.
-D <substring> Disable any rules with names having the substring <substring>. This option can be passed multiple times.
Can not be mixed with -t.
-e <events_file> Read the events from a trace file <events_file> in .scap format instead of tapping into live.
--enable-source <event_source>
Enable a specific event source. If used, all loaded sources get disabled by default and only the ones
passed with this option get enabled. Available sources are 'syscall' and all sources defined by loaded
plugins supporting the event sourcing capability. This option can be passed multiple times. This has no
offect when reading events from a trace file. Can not be mixed with --disable-source.
-i Print all high volume syscalls that are ignored by default for performance reasons (i.e. without the -A
flag) and exit.
-L Show the name and description of all rules and exit. If json_output is set to true, it prints details about
all rules, macros and lists in JSON format
-l <rule> Show the name and description of the rule with name <rule> and exit. If json_output is set to true, it
prints details about the rule in JSON format
--list [=<source>(=)] List all defined fields. If <source> is provided, only list those fields for the source <source>. Current
values for <source> are "syscall" or any source from a configured plugin with event sourcing capability.
--list-syscall-events List all defined system call events.
--list-plugins Print info on all loaded plugins and exit.
-M <num_seconds> Stop collecting after <num_seconds> reached. (default: 0)
--markdown When used with --list/--list-syscall-events, print the content in Markdown format
-N When used with --list, only print field names.
--nodriver Capture for system events without drivers. If a loaded plugin has event sourcing capability and can produce
system events, it will be used to for event collection.
-o, --option <opt>=<val> Set the value of option <opt> to <val>. Overrides values in configuration file. <opt> can be identified
using its location in configuration file using dot notation. Elements which are entries of lists can be
accessed via square brackets [].
E.g. base.id = val
base.subvalue.subvalue2 = val
base.list[1]=val
--plugin-info <plugin_name>
Print info for a single plugin and exit.
This includes all descriptivo info like name and author, along with the
schema format for the init configuration and a list of suggested open parameters.
<plugin_name> can be the name of the plugin or its configured library_path.
-p, --print <output_format> Add additional information to each falco notification's output.
With -pc or -pcontainer will use a container-friendly format.
With -pk or -pkubernetes will use a kubernetes-friendly format.
Additionally, specifying -pc/-pk will change the interpretation of %container.info in rule output fields.
-P, --pidfile <pid_file> When run as a daemon, write pid to specified file (default: /var/run/falco.pid)
-r <rules_file> Rules file/directory (defaults to value set in configuration file, or /etc/falco_rules.yaml). This option
can be passed multiple times to read from multiple files/directories.
-s <stats_file> If specified, append statistics related to Falco's reading/processing of events to this file (only useful
in live mode).
--stats-interval <msec> When using -s <stats_file>, write statistics every <msec> ms. This uses signals, and has a minimum
threshold of 100 ms. Defaults to 5000 (5 seconds).
-S, --snaplen <len> Capture the first <len> bytes of each I/O buffer. By default, the first 80 bytes are captured. Use this
option with caution, it can have a strong performance impact. (default: 0)
--support Print support information including version, rules files used, etc. and exit.
-T <tag> Disable any rules with a tag=<tag>. This option can be passed multiple times. Can not be mized with -t
-t <tag> Only run those rules with a tag=<tag>. This option can be passed multiple times. Can not be mixed with
-T/-D.
-U, --unbuffered Turn off output buffering to configured outputs. This causes every single line emitted by falco to be
flushed which generates higher CPU usage but is useful when piping those outputs into another process or
into a script.
-u, --userspace Parse events from userspace. To be used in conjunction with the ptrace(2) based driver (pdig)
-V, --validate <rules_file> Read the contents of the specified rules(s) file and exit. This option can be passed multiple times to
validate multiple files.
-v Verbose output.
--version Print version number.
--page-size Print the system page size (may help you to choose the right syscall ring-buffer size).

Conclusions

Overall, I had so much fun building parsers for memfd_syscall and diving into the Falco's main repository. Going foward, I'll be working on front-end side of things which is very exciting. I'll have to come up with UI/UX designs which takes be back to the days I started my web developemt journey. I'm super ready to flex my creative muscles 😁.

Blog: GSoC Week 2 updates

Tue, 11 Jul 2023 00:00:00 +0000

Alright, it's week 2 and I've got some updates. This week I learnt the different nuances and difficulties that comes while trying to compile a project for a new target. In my case it was WebAssemebly.

Parts of Falco, which will be used for the web application is completely written in C and C++. So, we'll be using the emscripten toolchain to compile the C/C++ code into wasm.

Compiling Falco to Wasm 😱

So, Falco's core logic is inside the libs repository.

We need to filter out libraries that won't be used and can't be compiled to wasm i.e kubernetes, grpc etc. There were a lot of modifications done, most of which are pre-processor checks for emscripten. Emscripten provies tools like emcmake and emmake to work with projects that are integrated using cmake build system. After that we wrote a github workflow that can sucessfully compile libs to wasm. It looks something like this.

 build-libs-emscripten:
 name: build-libs-emscripten 
 runs-on: ubuntu-latest
 steps:
 - name: Install deps 
 run: |
 sudo apt update
 sudo apt install -y --no-install-recommends ca-certificates cmake build-essential clang-14 llvm-14 git pkg-config autoconf automake libtool libelf-dev libcap-dev linux-headers-$(uname -r) emscripten

 - name: Checkout Libs 
 uses: actions/checkout@v3
 with:
 fetch-depth: 0

 - name: Git safe directory
 run: |
 git config --global --add safe.directory $GITHUB_WORKSPACE

 - name: Build and test 
 run: |
 mkdir -p build
 cd build && emcmake cmake -DUSE_BUNDLED_DEPS=True ../
 KERNELDIR=/lib/modules/$(ls /lib/modules)/build emmake make run-unit-tests -j4

You can find more information about the PR here.

Testing the shiny new Wasm build 😎

During the final steps of compilation, the c++ exceutable will be converted to a .js file with a .wasm file linked to it. I loaded the wasm module with the help of a fancy react hook provied by my mentor, Jason and to my suprise! it worked without any additional configurations.

The above image contains the help funtion of a CLI interface. This is a simple std::cout<< statement that logs the entire string into the console.

Conclusions

Overall, This week was super productive and informative for me. For the next week, I'm looking into adding parsers for the syscalls that I added previous week. Also we'll be supporting wasm build for Falco's main repository, which looks very exciting!

Blog: GSoC Week 1 Reflections

Tue, 27 Jun 2023 00:00:00 +0000

Hello Folks!, my name is Rohith, and I am thrilled to share my experiences and reflections on the first week of the Google Summer of Code (GSoC) period.

This is an exhilarating time for participants like myself as we embark on our coding journey and dive into the world of open source development.

A huge thank you! to all the community members accepting me as one of them ❤️.

My Project: Falco Playground

Falco is a security tool that comes with a rule language for its runtime security engine. However, there is currently no official and user-friendly integrated development environment (IDE) for writing and testing Falco rules. To address this gap, we propose a project that aims to add WebAssembly as a supported compilation target for Falco.

By using the Emscripten toolchain, we plan to create a web-based single-page application that serves as a development environment for security rules. This means you can write and test Falco rules right inside your browser without the need for any backend infrastructure. The end result will be similar to the Go Playground, where you can experiment with code in a seamless and accessible manner.

The project offers an exciting opportunity to explore various technologies within the cloud-native landscape. It involves working with low-level system code in close proximity to the Linux kernel, WebAssembly world, and engaging in frontend development for web application. By combining these different aspects, we aim to provide a convenient and comprehensive solution for developing Falco rules with ease.

New beginnings 🚀

By contributing to the project prior to the GSoC period, I had the opportunity to understand the project's ecosystem, gain insights into its development processes, and establish myself as a valuable member of the community. It provided me with a deeper understanding of the project's goals and challenges, enabling me to better align my proposed solutions and goals for the GSoC period.

During this pre-GSoC contribution phase, Jason Dellaluce, my mentor, played a crucial role in guiding and supporting me. Jason provided valuable feedback on my early contributions, helped me navigate the project's codebase, and encouraged me to explore new areas for improvement. My ongoing collaboration with Jason played a crucial role in my development as a contributor, paving the way for a fruitful journey through GSoC.

As Week 1 of the official GSoC period began, my pre-GSoC contributions served as a foundation for diving deeper into the project. The knowledge and familiarity I gained before allowed me to hit the ground running and make meaningful progress from the very beginning. It also reinforced the strong mentor-mentee relationship with Jason, as we had already established a rapport and had a shared understanding of the project's context.

Here is a summary of pull requests (PRs) I have submitted:

PR #1: Test For command falco -i (ignore default events)
- Description: The falcosecurity/testing repository contains regression a test suite for Falco and other tools in its ecosystem. I contributed by adding a new test case for Falco's help output when used with thie -i flag. I contributed to two other flags.
PR #2: Semver check for RequiredAPIVersion values
- Description: This pr checks if user's RequiredAPIVersion follows semver system and checks if is compatible with internally-supported API version
PR #3: Feat: Support for memfd_create syscall
- Desciption: Whenever the kernel is updated and released, a new syscall or updated version of syscall may be added. This can create new vulnerabilities that can allow malicious activity from Falco to go undetected. Therefore, we need to update Falco's internal syscall table to address vulnerabilities. This PR adds support for the memfd_create syscall
PR #4: Feat: Support for pidfd_getfd syscall
- Description: Same as above, this PR adds support to the pidfd_getfd syscall

Conclusions

In conclusion, my early contributions to the project before the GSoC period commenced provided me with a head start, enabling me to make a more significant impact right from the start. The guidance and support from Jason, combined with my pre-GSoC involvement, allowed me to seamlessly transition into the official GSoC period and continue building upon my previous contributions.

Please stay tuned for updates and feel free to reach out to me via the CNCF Falco community channels. Your guidance, feedback, and support are invaluable.

Thank you all for your warm welcome, and here’s to an exciting and fruitful GSoC.

Falco – Gsoc

Blog: Halfway Through GSoC 2024: My Progress and Plans with Falco

My Project: Enhancing Falco's Event-Generator

My Journey So Far:

Detailed Look at the Merged PRs:

PR1: Add support for declarative yaml file testing

PR2: Add container runner support

Future Work:

Conclusion:

Blog: Gsoc Week-3 and Week-4 updates

Wasm Target For Falco 🦅

Conclusions

Blog: GSoC Week 2 updates

Compiling Falco to Wasm 😱

Testing the shiny new Wasm build 😎

Conclusions

Blog: GSoC Week 1 Reflections

My Project: Falco Playground

New beginnings 🚀

Conclusions