Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Falco 0.36. Rules Messaging #132

Closed
incertum opened this issue Aug 18, 2023 · 2 comments
Closed

Falco 0.36. Rules Messaging #132

incertum opened this issue Aug 18, 2023 · 2 comments
Labels
kind/documentation Improvements or additions to documentation

Comments

@incertum
Copy link
Contributor

What to document

Discuss the rules release note and general messaging for Falco 0.36.0 with respect to rules changes.

CC @leogr @LucaGuerra @loresuso @darryk10 @Andreagit97 @jasondellaluce

@incertum incertum added the kind/documentation Improvements or additions to documentation label Aug 18, 2023
@incertum
Copy link
Contributor Author

Starting with some thoughts around libs changes that influence Falco's existing fields and rules behavior:

We are excited to share that we have undertaken enhancements to Falco's underlying libraries. As a result of these improvements, we have achieved a higher level of accuracy and data quality regarding the existing proc.exepath and the process tree reconstruction in general. This step forward reinforces our commitment to refining Falco and providing you with an even better user experience.

In more detail:

  • The proc.exepath process executable path is now obtained through direct retrieval within the kernel drivers by converting the dentry into an ASCII path name when a process is spawned. In the past, we resolved the exe argument in userspace by utilizing the process's cwd when the path was not absolute. Conversely, if exe was absolute, the exepath was equivalent to exe. The new implementation ensures the extraction of the authentic and accurate disk path of the executable when it resides on the disk. An interesting scenario where the field's significance has changed is when the executable path was symlinked. Previously, distinguishing between a symlink and the actual executable path on the disk posed a challenge. Now, we can confidently assert that proc.exepath consistently represents the genuine executable path on the disk. Should you still require information about the symlink, a new field has been introduced: proc.exepath_symlink.
  • The Linux kernel presents intriguing edge case behaviors, where the direct parent process might genuinely have already exited. For instance, the container_entrypoint macro and its description offer a perfect illustration of this. In the past, Falco encountered difficulties in continuing to reconstruct the parent process lineage in such situations. To address this, we've enhanced Falco's logging capabilities. Now, even in scenarios where the parent process has exited, Falco can continue reconstructing the process tree. This enhancement enables us to consistently provide an accurate and up-to-date representation of how the Linux kernel perceives the process tree at any given moment. Nevertheless, it's crucial to highlight a key aspect: While logging a history of all spawned processes might seem synonymous with the process tree lineage, this equivalence does not always hold true. Cases involving rapid PID replacements and other factors can challenge this assumption. Please bear this in mind and understand that Falco's approach mirrors the Linux kernel's process tree view at a specific point in time.

[Note: I am trying to strike a balance between providing some technical details, but not too much either]

As I have time I will continue adding thoughts to this issue ...

@leogr
Copy link
Member

leogr commented Aug 21, 2023

Ref about syslinks falcosecurity/libs#1300

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants