When there is no work to do, i.e. when all config watching is disabled,
there is no need to keep the restart_handler running. Disable it in this
case.
This is helpful to do on nodes where there is little to no headroom in
terms of open inotify watches (as per the inotify/max_user_instances
configuration), as can happen on nodes populated with other software
that also watch the filesystem for changes. If Falco is run on such a
node, it may fail to start due to functionality the app does not even
intend on using.
This has one change in terms of behaviour, however: the dry-run restarts
will no longer occur. As there is still never going to happen a real
restart, I understand it as unlikely for there to be a proper need for
dry-run restarts.
Signed-off-by: Mariell Hoversholm <mariell@grafana.com>
As buster reached its EOL, the official debian repo URL doesn't
host anymore buster packages info. For this reason, change the URLs
to point to the `20250630T203427Z` snapshot, which still contains
them.
Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>
In case multiple sources are enabled, each source has its own `libs_metrics_collector`
with correct flags, so that it can retrieve all metrics.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Moreover, rename `falco_metrics::` methods to better expose
they return prometheus metrics.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Co-authored-by: Samuel Gaist <samuel.gaist@idiap.ch>
Refactor `::to_text` a bit to be more clear.
Also, we will push agent_info and machine_info only for the first
inspector that exposes them, to avoid duplicated entries in the prometheus text.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
* For consistency don't make first run metrics log special
* Remove firt tick variable altogether to enable metrics logging immediately after startup/reload
Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
distributions such as SLES. The cmake file for c-ares sets
'CARES_LIB' destination directory to '${CARES_SRC}/lib' but when the
bundled c-ares is compiled it produces a binary which is placed in
the '${CARES_SRC}/lib64' directory.
This is due to the fact that the bundled c-ares expands
${CMAKE_INSTALL_LIBDIR} to 'lib64' and not to 'lib' which is
expected by 'CARES_LIB'.
The fix is to enforce the building process of the bundled c-ares
to place the produced binary in 'lib'.
Signed-off-by: Tero Kauppinen <tero.kauppinen@est.tech>
Merge-strategy for included config files must now be
specified as yaml map of the form:
- path: foo
strategy: bar
If `strategy` is omitted, or the old `string-only` form is used,
`append` strategy is enforced.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
By default we now use the `append` merge-strategy:
* existing sequence keys will be appended
* existing scalar keys will be overridden
* non-existing keys will be added
We also have an `override` merge-strategy:
* existing keys will be overridden
* non-existing keys will be added
Finally, there is an `add-only` merge-strategy:
* existing keys will be ignored
* non-existing keys will be added
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Refs #3503: we need it because rpm pre/post install/remove scripts
are evaluated at rpm package building time.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Defining `exceptions` with empty `values` is a legitimate use case since the values can be added to another rules file. Even when values are not populated elsewhere, Falco can work without issues; that's the reason why the `values` field is not required. With this change, we avoid emitting useless validation warnings in situations where exceptions are just defined but not actually used because values are not being provided.
Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
Container plugin cannot be dynamically loaded on musl build, therefore
some falcosecurity/testing tests are failing on it.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Also, remove `container_id container_name` fields from `-pc` output.
These fields are now automatically appended since the `container` plugin
marks them as suggested.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Also, default falco.yaml will only host container plugin configuration but won't enable the plugin.
Instead, a configuration override file will be installed only on linux non-musl deployments, enabled the plugin.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Move actions not requiring config to be loaded before `load_config`
action. This avoid resource waste. Notably, `print_help` is
promoted as first execution action. Moreover, set actions lists to
constant expressions.
Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>
Add additional unit tests to verify that rule loading fails when a
second rules object has a different source but the name of an existing
rules object.
Also add tests for additional rules having an empty source.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
In places where a second rule definition might replace, append to, or
replace items from a base rule, ensure that the source of the second
rule definiton matches the first.
This already existed for defines, but for other changes. There was a
bug where a second definition might exist for a different source, but
the additional rule was used anyway.
This now returns the same error for these other changes e.g. "Rule has
been re-defined..." as define.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
It's possible that someone might want to override a property for a
non-syscall rule source. To assist in this, decode any source property
for rules with append/override and save it in the rule_update_info
object. For the source property only, the value for source can be
empty e.g. 'source: ' or an empty string e.g. 'source: ""'. Both of
those are considered valid but result in an empty source.
A later change will ensure that the sources match up when
appending/redefining/overriding/enabling.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add a test for checking that compile_output::clone() returns equal
values, specifically in the case of derived values.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add an equality operator for indexed_vector.
As indexed_vectors commonly hold falco lists/macros/rules, also add
equality operators for those structs. For condition/sinsp_filter
shared_ptrs, the operator checks that the shared_ptrs point to the
same underlying memory.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add a clone() method that can be overridden by subclasses. This allows
copying compile state when needed in a way that preserves
polymorphism.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Introduce host_netinfo stats family to hold information regarding host
networking. At the moment, it only provides ipv4 and ipv6 addresses
list for each interface available on the host. The naming schema for
the introduced stats is
falco.host_netinfo.interfaces.<ifname>.protocols.<ipv4|ipv6>.addresses.
Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>
Using JSON as value prevents any meaningful aggregation for the stats.
Splitting these information into multiple labels can drastically
increase the number of dimensions, as the number of interfaces and
addresses can be high in some environment. Moreover, these information
are not currently refreshed, even if they can frequently change. Given
these reasons, remove ifinfo_json from stats and metrics.
Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>
Also, moved yaml_helper under engine/ folder.
Ported rule json schema validation in the engine.
Also, updated rule_loader tests to check for validation.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
There are systems, like Nix derivations where the build process
does not have network access in order to enforce reproducibility.
This patch allows people building Falco to optionally skip the build
of falcoctl with `-DADD_FALCOCTL_DEPENDENCY=OFF` and point to their own
self-backed, or pre-fetched rules files with
`-DFALCOSECURITY_RULES_FALCO_PATH=<some-path>` and
`-DFALCOSECURITY_RULES_LOCAL_PATH=<some-path>`.
For context, I needed to apply these patches while building the
project with Nix in https://github.com/tembleking/falco-nix but I think
that would be benefitial for the community to have also these options
open, and that would also make Falco feasible to be added to the
nixpkgs repository at https://github.com/nixos/nixpkgs
Signed-off-by: Fede Barcelona <fede_rico_94@hotmail.com>
Modify evttype_index_ruleset to derive from indexable_ruleset instead
of having its own implementation of segregating filters by ruleset
id/event type.
An evttype_index_wrapper contains a falco rule and filter, and
implements the methods required by the template. run_wrappers()
evaluate the filter as before, without the segregation by ruleset
id/event type.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Now that custom rules loading implementations (and related, custom
rulesets) can be swapped into falco in a customizable way, there is
some functionality in evttype_index_ruleset that could be used by
other rulesets, specifically the part that segregates filters by
ruleset and enables/disables filters based on name substring + tags.
To allow for this, create a new template indexable_ruleset<class
filter_wrapper> which derives from filter_ruleset and segregates the
filter_wrappers by ruleset. It also optionally segregates
filter_wrappers by event type.
The filter_wrapper class is an object that can return a name, tags,
and sc/event codes.
The main interfaces for classes that derive from indexable_ruleset are:
- add_wrapper(), which provides a filter_wrapper to the
indexable_ruleset. This is generally called from
add()/add_compile_output(), which must be implemented by the derived class.
- run_wrappers(), which must be implemented by the derived class and
is called for event processing.
Most of the methods required by filter_ruleset are implemented by
indexable_ruleset and do not need to be implemented by the derived
class.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Also, rename `Experimental` -> `Incubating` and move `prometheus_metrics_enabled` to `Incubating`.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
The textual content was fixed but not the metrics name.
Co-authored-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
As agreed upon during review, use this name to get started. If more
backends were to be added, the configuration structure will be updated.
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
As falco may update its state at any time and thus its inspectors objects,
keeping pointers to them may end up in using dangling values.
Therefore, use the state of the application when requesting metrics.
Optimizations such as caching of mostly static values will be done in
a follow up patch.
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
This makes things easier to pass around like when starting the
web server.
This has the added benefit of simplifying further extension such as
making the metrics endpoint name configurable without adding yet another
parameter to the start function.
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
It was checking twice for prometheus configuration rather than metrics and then prometheus.
Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
Moreover, added a couple more tests.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Co-authored-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Moreover, do not trigger an exception when an included file is not present; just print a warning.
Finally, add more tests.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
The PR introduces a `includes` keyword in the config file,
that points to a list of strings (paths to other config files).
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Includes a handful of naming changes. A notice to
https://falco.org/docs/metrics/falco-metrics/ will be added well
in advance of Falco 0.38.0
falco.hostname -> evt.hostname to be consistent with the newer evt.hostname filtercheck
cpu_usage_perc_total_host -> host_cpu_usage_perc
memory_used_host -> host_memory_used_kb (or host_memory_used_mb)
procs_running_host -> host_procs_running
open_fds_host -> host_open_fds
memory_rss -> memory_rss_kb (or memory_rss_mb)
memory_pss -> memory_pss_kb (or memory_pss_mb)
memory_vsz -> memory_vsz_kb (or memory_vsz_mb)
container_memory_used -> container_memory_used_bytes (or container_memory_used_mb)
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
When hitting that part, the restart signal is triggered and the code
leaves the loop, hence setting should_restart as false makes no sense
in this context.
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
The implementation provides more or less the same implementation
and thus it makes more sense to base it on std::runtime_error.
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
Added option for insecure http driver download in the docker-entrypoint.sh script. By passing --http-insecure to the container via an argument, the flag is forwarded to the falcoctl driver install command.
Signed-off-by: Tom Müller <60851960+toamto94@users.noreply.github.com>
Add a unit test for providing an alternate rules loader that also
demonstrates how users can define sub-classes that may want to extend
the falco rules syntax.
This test creates a test rules reader/collector/compiler that supports
top-level objects "test_object". The reader reads them and saves them
in the collector. The compiler iterates over all test_objects and puts
the property values into a single set<string>.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Move the part of compile_rule_infos that actually compiled a condition
string into a sinsp_filter into a standalone method
compile_condition(). That way it can be used by classes that derive
from rule_loader::compiler() and want to compile condition strings.
This implementation also saves the compiled filter as a part of the
falco_rule object so it does not need to be compiled again wihin the
falco engine after rules loading.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Some rulesets may need information which is held by the falco_engine
that created this ruleset. So define a set of functions in a struct
and have setters/getters for those functions in the base class.
Derived classes can use the struct's functions to obtain the falco
engine information.
The only function so far is to obtain the filter_ruleset for a given
event source.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
To support subclasses that may extend the falco rules format, add
additional error/warning/item types for an extension item.
When subclasses report errors and warnings, they can use these
codes/item types in context objects and still provide an exact
line/column context.
Also make some previously static functions in rules reader protected
methods so they can be used in sub-classes.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
In order to support external rules loaders that may extend the falco
rules format with new top level objects, move away from providing
individual filter objects to the filter_ruleset via calls to add().
Instead, pass the entire compile output returned by the compiler to
the ruleset using a new method add_compile_output(). Custom users can
then cast back the compile output to the appropriate derived class for
use in the ruleset.
Move the declaration of the compile output to a standalone class so it
can be used by rulesets without including the entire rules loader
header files, and add a new factory method new_compile_output() to the
compiler so it can create a derived class if necessary.
This change is
backwards-compatible with existing rulesets, as the default
implementation of add_compile_output() simply iterates over rules and
calls add() for each rule.
This change also speeds up rule loading. Previously, each rule
condition was compiled twice:
1. First, in the compiler, to see if it was valid.
2. Second, in the falco engine before providing each rule to the
ruleset.
Add the compiled filter to the falco_rule object instead of throwing
it away in the compiler.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
In some cases, a user of the falco engine may want to extend the falco
rules format to provide additional objects to the rules file.
To support that, add a new method set_rule_loader() that allows a user
to provide classes that derive from
rule_loader::{reader,collector,compiler} and read those additional
objects from the rules file.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add unit tests for add_source() and its related find_*_for_source()
methods. The test just verifies that the values provided to
add_source() are the same as the values returned by the find methods.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add methods that allow looking up the factories provided to
add_source(). This allows not having to keep track of the factories
outside of the engine.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Inline find_source as it can be called in the event processing path.
Also take the cached variant that assigns/uses m_syscall_source_idx
and put it in find_source() instead of process_event().
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add unit tests for enabling/disabling rules, covering:
- matching names by substring
- using "" to match all rules
- matching names exactly
- using ruleset ids in addition to ruleset names
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add alternate enable_* methods that allow enabling rulesets by ruleset
id in addition to name. This might be used by some filter_rulesets to
enable/disable rules on the fly via the falco engine.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Also, env variables always have precedence over dialog (ie: if they are set, we always skip dialog).
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Also, properly warn the user that deprecated CLI options will be ignored
when the new `engine` configuration key is in use.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Moreover, renamed driver kinds to use better naming, and move driver's related
config keys under `driver.$kind`.
Added DEPRECTATION notices on CLI options, and in falco.yaml.
DEPRECATED options (both CLI and config ones) will have priority over the new ones,
to retain compatibility with existing configs.
DEPRECATED options will be dropped in Falco 0.38.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Co-authored-by: Andrea Terzolo <andreaterzolo3@gmail.com>
This `init({});` in the falco_configuration constructor is unnecessary
since when we call the action `load_config`, if we don't have a config
file, we will call the same `init` we have just removed. This cleanup
avoids calling `falco_configuration::init` 2 times.
Signed-off-by: Andrea Terzolo <andreaterzolo3@gmail.com>
address
Currently the webserver is listening on the hard coded 0.0.0.0. This
patch keeps this default but allows the administrator to change it.
Signed-off-by: Samuel Gaist <samuel.gaist@idiap.ch>
Open Source Security Foundation Scorecard [1] is an automated tool
that assesses a number of important checks associated with
software security and assigns each check a score of 0-10.
Also, the OSSF Scorecard is one of the metrics monitored by
the CNCF CLO Monitor [2].
1. https://github.com/ossf/scorecard
2. https://github.com/cncf/clomonitor
Signed-off-by: Massimiliano Giovagnoli <me@maxgio.it>
Workaround for older GLIBC versions (< 2.35), where calling timer_delete()
with an invalid timer ID not returned by timer_create() causes a segfault because of
a bug in GLIBC (https://sourceware.org/bugzilla/show_bug.cgi?id=28257).
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
In order to allow the user to supply environment variables in standard
ways performed in other applications the get_scalar function has been
extended to support defining an environment variable in the format
`${FOO}`. Environment variables can be escaped via defining as `$${FOO}`.
As this handles some additional complexity, a unit test has been added
to cover this new functionality
Signed-off-by: Daniel Wright <danielwright@bitgo.com>
Fixes#2352
Needed to refactor the target_id code paths to allow this to be used in
env printing and sourcing.
Signed-off-by: hjenkins <henry@henryjenkins.name>
Old gcc versions (e.g. 4.8.3) won't allow move elision
but newer versions (e.g. 10.2.1) would complain about
the redundant move.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Deprecate `-d` option (currently broken).
Symptoms included the message queue filling up without popping any messages
even though events were handled normally.
Maintainers decided to deprecate not needed `-d` option while keeping
the useful `pidfile` command args option.
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
In https://github.com/falcosecurity/falco/pull/2043 we've added logic
for relocating tools on Flatcar when running falco-driver-loader in kmod
mode. This logic is relevant for BPF mode, too, which is currently
broken on Flatcar. Call flatcar_relocate_tools in BPF mode, too.
Signed-off-by: Johanan Liebermann <jliebermann@microsoft.com>
Added a set method for the rule matching strategy on the engine.
This allows to modify the stategy at runtime withotu the need to
rebuild an engine from scratch.
Signed-off-by: Lorenzo Susini <susinilorenzo1@gmail.com>
bump Ubuntu version on tests-driver-loader-integration job to fix a
verifier issue as a temp workaround
Signed-off-by: Andrea Terzolo <andreaterzolo3@gmail.com>
This commit will unquote URL's allowing them to be supported by
libcurl and eliminate any errors when a valid (quoted) URL is supplied
by a user.
Closes#2579
Signed-off-by: Daniel Wright danielwright@bitgo.com
add send_numeric_zero_values config to allow users to save space
when using metrics option, while still also allowing
to send all keys (especially because we don't document the schema)
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
To supoprt the use of outputs that are documented in the falco
examples (e.g. jq piped to curl) I would like to propose including
these tools in the falco-no-driver image. They add a very minimal
size and dependency to the image but would make things a lot easier
for users getting started.
Closes#2580
Signed-off-by: Daniel Wright <danielwright@bitgo.com>
* rephrase descriptions for numerous config options
without changing the original content, meaning changes
reflect language improvements and minor extensions
(such as adding justifications or what it is) only
* add Falco environment variables section
* add Guidance for Kubernetes container engine command-line args settings
* general rewrap formatting w/ IDE
* minor additional re-ordering of configs
* minor general language adjustments
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
* add an index for logical categories
* move configs around without changing description content,
solely add a uniform header to each config
* indicate "Stable" or "Experimental" for most configs
to indicate current stability or maturity
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
* Ensure each metric field name more consistently adheres to the grammar used in Falco rules:
* `falco.`: new field class representing userspace counters, statistics, resource utilization, or necessary information fields
* `scap.`: new field class represents counters and statistics mostly obtained from Falco's kernel instrumentation before events are sent to userspace, but can include scap userspace stats as well
* minor cleanup
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
* prefix counters and stats belonging to kernel space w/ `k.` else `u.` for userspace
* add n_drops_perc from old stats writer schema
* revert one change: file output shall reflect exact same "output_fields" key as rule output, note that src is already part of the "output_fields" schema.
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
These changes break the old stats file output schema and consolidates
them with the new schema.
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
- avoiding inspector to be allocated for each rule
- use two boolean values for expecting macros and lists
- move items of lists alongside name, under info
- use snake case for json output, like we do for e.g alerts
- correctly retrieve evt names
- consider two levels of lists for exception operators
Signed-off-by: Lorenzo Susini <susinilorenzo1@gmail.com>
Adding the proper link to the brand guides
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Signed-off-by: Aizhamal Nurmamat kyzy <aizhamal@google.com>
Instead, store image tarballs as artifact and download them in `reusable_publish_docker.yaml` workflow,
to be finally merged in multi-arch images and pushed.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Support for user provided CA certificate that can verify the remote server. Users
can provide path to the CA certiface store by providing a path to the dir or to the
CA store file. If needed users can decide to tell Falco to not verify the server.
Signed-off-by: Aldo Lacuku <aldo@lacuku.eu>
The test now take in accoint pre/post-conditions of the actions,
usage of the -A option, and the newly-introduced base_syscall
user configuration. This also makes sure that the event selection
properly handles generic events and options/configs precedence.
Co-authored-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
* Plus minor adjustments to ensure correct state_event_set for all configurations
* Ensure valid check_for_rules_unsupported_events for all configurations
* Remove user input validation warning -> re-introduce in follow up PR
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
See https://github.com/falcosecurity/falco/issues/2373
Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
Co-authored-by: Stanley Chan <pocketgamer5000@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
* address reviewers feedback
* improve clarity around new -A and -i behavior
* additional cleanup (e.g. use generic set operations only)
* extend unit tests
Note: sinsp ppm sc API is undergoing a refactor, therefore current lookups are interim
and will subsequently be refactored as well.
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Define new -A behavior in configure_interesting_sets
* default: all syscalls in rules included, sinsp state enforcement without high volume I/O syscalls
* -A flag set: all syscalls in rules included, sinsp state enforcement and allowing high volume I/O syscalls
Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Moreover, now falcoctl service is enabled by default. It being bound to falco.target
allows us to avoid it running when falco.target is not running.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Eg: when building Falco docker image, and installing Falco package, we don't want it to build any driver.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Cleaned up unused vars in postinst scripts.
Finally, only show dialog window in interactive shells.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
AmazonLinux uses `gcc-$Vers`, like gcc-10, but our regex prevented that to work.
Instead, rely on the fact that **real** gcc has some `--version` fixed output.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Manage it via a bash dialog interface.
Moreover, use falco-driver-loader instead of dkms to build bpf/kmod after package install.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
In the copy constructor and assignment operator for falco_source, also
copy the ruleset along with factories/name.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Now that ASTs contain parse positions, use them when reporting errors
about unknown macros.
When doing the first pass to find all macro references, save macros as
a map<macro name,parse position> instead of a set<macro name>. While
making that change, change the visitor struct to use references
instead of pointers.
In the second pass, when reporting any unresolved macro references,
also report the parse position.
The unit tests also check that the positions of macros are properly
returned in the resolved/unresolved maps.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Now that ASTs have parse positions and the compiler will return the
position of the last error, use that in falco rules to return errors
within condition strings instead of reporting the position as the
beginning of the condition.
This led to a change in the filter_ruleset interface--now, an ast is
compiled to a filter before being passed to the filter_ruleset
object. That avoids polluting the interface with a lot of details
about rule_loader contexts, errors, etc. The ast is still provided in
case the filter_ruleset wants to do indexing/analysis of the filter.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Docker builder image was updated to remove the libelf and libz deps as they are now properly bundled, in BUNDLED_DEPS mode.
Finally, circleci musl job was updated to enforce the use of alpine-provided libelf package, since it is already static,
and building libelf on musl is pretty cumbersome.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
The optimization in https://github.com/falcosecurity/falco/pull/2210
had a bug when the engine uses multiple sources at the same
time--m_syscall_source is a pointer to an entry in the indexed vector
m_sources, but if add_source is called multiple times, the vector is
resized, which copies the structs but invalidates any pointer to the
vector entries.
So instead of caching m_syscall_source in add_source(), cache it in
process_events(). m_sources won't change once processing events starts.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
`open_params` is read from the falco YAML configuration file and parsed using Go's URL.
For example:
c349be6e84/plugins/k8saudit/pkg/k8saudit/source.go (L41-L42)
Go's URL parser does not handle whitespace, so if a user defines the `open_params` in the falco configuration file as follows
```yaml
open_params: >
/file/path
```
the parser returns an error. To avoid this, we now trim this parameter so no whitespace will be left for Go's URL parser to error out on.
For reference see #2262.
Signed-off-by: Yarden Shoham <hrsi88@gmail.com>
improve also some logs for `m_syscall_buf_size_preset` configuration errors
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Adapted API to sinsp::open API break, and simple consumer API break.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it>
Instead of using a falco_rule struct on the stack, use a single value
inside the falco_source struct. It's mutable as find_source returns a
const struct.
At very high event volumes (> 1M syscalls/second), even the tiny time
it takes to create/destroy the struct starts to add up, and this
switch has some small cpu savings.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
When doing some testing of falco on very high event volumes (> 1.5M
events/second), I found that the time taken to look up a falco_source
struct had a non-negligible contribution to cpu usage.
So instead of looking up the source from the source_idx every time,
separately save the source for syscalls in the falco_engine object
directly. The separately saved copy is only used once someone calls
add_source with source="syscall".
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
According to the FHS 3.0 (https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html), transient UNIX-domain sockets should be placed under the directory /run, so this commit updates the implicit value generated by the application.
Signed-off-by: Vicente J. Jiménez Miras <vjjmiras@gmail.com>
Now, the action takes care of inizializing all app inspectors
(just one in capture mode, one for each evt source in live mode), and of
registering and initializing all loaded plugins in the right inspector as needed.
The plugin initialization logic, which also involves the filtercheck list
population and checks, was moved and refactored from the previous
implementation of the load_plugins action.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Now, the action is in charge of loading all plugins and initializing:
- the offline inspector
- the list of loaded event sources
- the list of loaded plugins and their config
After this action runs, plugins are loaded but not yet initialized.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
If there is a file in `/etc/VERSION` the script assumes that it is running in a minikube
enviroment. Furthermore the logic in building the `KERNEL_VERSION` has been updated
according to how the kernel and probe modules are saved in the S3 bucket. The kernel version
for the minikube kernels includes also the minikube version.
Signed-off-by: Aldo Lacuku <aldo@lacuku.eu>
When running falco-driver-loader in local we need to set some config variables to meaningful values.
Those variables usually are set by the CI during the image/packages builds. The changes introduced
by this commit allow to set them at start-up time using env variables
Signed-off-by: Aldo Lacuku <aldo@lacuku.eu>
Update a few tests related to rules loading to use new names for
items (e.g. "rules content" for top level errors instead of "file")
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Use an enum instead of a string for the item_type aka "parts of a
rules file" field of contexts.
The set of values is mostly defined by the contexts that were already
created. There are a couple of forward-looking values for rule
outputs/macro conditions/etc. that may be useful for later.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
In #2098 and #2158, we reworked how rules loading errors/warnings were
returned to provide a richer set of information, including
locations/context for the errors/warnings.
That did *not* include locations within condition expressions,
though. When parsing a condition expression resulted in a
warning/error, the location simply pointed to the condition property
of the rule.
This commit improves this to handle parse errors:
- When libsinsp::filter::parser::parse() throws an exception, use
get_pos() to get the position within the condition string.
- Add a new context() constructor that takes a filter pos_info instead
of a YAML::Mark.
Now that positions aren't always related to the location of yaml
nodes, Make up a generic "position" struct for locations and convert
YAML::Mark and parser positions to a position struct.
Also allow a context to contain an alternate content string which is
used to build the snippet. For contexts related to condition strings,
the content is the condition.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This new model uses an async worker and a concurrent queue to handle
stats writing. This ensures better performance, because the live event
processing loop will just need to do a push on the queue instead of writing
to a file (only when the timer triggers), and should be thread-safe by design.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
In outputs it could be confusing to see a line:
<filename>: Ok
followed by a set of warnings.
To differentiate this, add a top level status "Ok, with warnings" when
rule loading was successful but had warnings.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
The methods that throw exceptions from stringified results need to
additionally pass a rules_contents_t struct. This also meant that they
need to call the filename + content version of load_rules.
To avoid some duplicate code between the two load_rules_file methods,
move the work of opening the file into a private method
read_file(). It can throw an exception, which is passed through for
the void return method and caught + converted into a load_result error
for the method that returns a load_result.
Also, to avoid duplicate code between the void load_rules and
load_rules_file methods, add a private method interpret_load_result()
which throws an exception if the result has an error and prints
warnings otherwise if verbose is true.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Application changes to support multiple files when stringifying rules
results:
- In both validate_rules_files and load_rules_files, instead of
loading each file individually and then calling load_rules(), add a
separate step that loads all the files at once. The actual rules
content strings are held in a vector. The map from filename to
content (reference) points to entries in that vector.
- Both actions do the same work for this step, so put the
implementation in a shared application template method read_files
that works on iterators. It uses itertors because the load filenames
are a list and the validate filenames are a vector.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
The old version of rules_result assumed that all errors/warnings were
related to a single file. That was generally correct for errors, as
rules parsing always stopped at the first error, so there is only one
relevant file.
However, for warnings that was not the case. When reading multiple
files A and B, you might get a warning from file A *only* after
reading file B. For example, B might redefine a rule in such a way
that you could get unused list/macro warnings from file A.
To properly address this, make some changes to how contexts are
managed:
- Instead of creating snippets at the time the error/warning was
generated, create snippets at the time the error/warning is
converted into a string. This requires passing all rules contents to
as_string()/as_json(), so define a
falco::load_result::rules_contents_t map from filename to rules
content (reference) and pass it in as_string/as_json(). Snippets are
now generated from the rules content matching the filename in the
context.
- When creating warnings/errors, there's no need to pass along the
rules content. This is only used when converting an error into a
string/json.
Also change snippet() to handle potentially very long lines. Instead
of always printing the entire line matching a location, print up to
snippet_width(param, with default 160 chars)/2 characters surrounding
the column from the location.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
The latest released falco always prints full details on errors when
used with -r (read rules)/-V (validate rules). However #2098 changed
this to only print full details when verbose is true.
Fix the regression by always printing errors when loading
rules. Warnings will be printed only with -v.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update tests that validated rules files (typically looking for
errors/warnings) to use the new result struct + json based validation:
- When validating rules files, always use json output.
- In test cases, instead of parsing stderr/stdout, use new test
properties "validate_ok", "validate_errors",
"validate_warnings". These parse the json output and look for
specific tuples of (error code, error message, item type, item name)
in the output.
- There were a few tests that were actually validation tests but using
the -r argument to load rules. Convert them to validation tests. In
one case, split the test into two separate tests--one for
validation, one ensuring that the rule doesn't match anything.
- There were a couple of tests that were duplicates of existing
validation tests, just checking for the error in a different
way. Remove them.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update the load_rules_files and validate_rules_files actions to use
the new falco_engine methods that return a rules result struct. The
app action interface is the same, returning ::fatal on error,
ok()/exit() otherwise. The difference is how any warnings/errors are
obtained--from the struct instead of an exception.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Changes to the rule loader to support result objects:
- Instead of throwing falco_exception on internal error, throw a
rule_load_exception instead, which contains distinct
error/message/context information.
- A context object contains a chain of location structs chaining from
the document root to the object where the error occurred. Each
location has a file position (as a YAML::Mark), an item
type (e.g. "rule", "list", "exception"), and an item name (e.g. "Write
Below Etc"). This will allow showing the exact location of an
error (e.g. list item/exception field) while also remembering the item
that contained it.
- All the _info structs now contain a context so errors that occur
after yaml parsing can still point to the original location in the
yaml file.
- rule_loader::result is an implementation of the abstract class
defined in falco_load_result. The implementation keeps track of a
list of errors/warnigns that used to be in the configuration object,
- Clean up compile_ methods to just throw rule_load_exceptions or
return nothing, and ensure that all rule_load_exceptions are caught in
compile(). When caught, errors are added to the result object.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Modify rule reader to use a result struct for errors and warnings:
- Instead of throwing a falco_exception to pass back errors, use a
rule_load_exception, which contains distinct error codes, messages,
and a context that points to the location of the error.
- The static method context_yaml_get_context() has moved to a method
of the rule_loader context object + the result as_string() method.
- As objects are parsed, create relevant context objects as reading
drills down into the contents of a rule/list/exception. This will
enable for specific errors in, say, the middle of an exception/list
while remembering the object that contains it.
- Modify decode_val()/decode_seq() to always return errors as
exceptions. Previously, it was a mix of a bool return + some
exceptions.
- decode_val()/decode_seq() are now more consistent about returning
distinct errors for the property not existing, the property existing
but not being a scalar/sequence value, and not being convertable to
the templated value.
- Combine the two nearly identical decode_seq() functions into a
single one that uses a lambda to perform the final step of adding to
the vector/set.
- There are some item-specific decode_xxx functions for specific
item properties like tags, exceptions fields/comps/values, etc.
that call the above functions.
These changes simplify the calls to decode_seq()/decode_val() as they
don't need to add their own errors when returning false. Also some
calls weren't checking the return value.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Now that we have a result struct and set of warning codes, change the
filter_warning_resolver to use them. This involves populating a set of
warning codes instead of strings.
Also, the methods to format warnings into human-readable strings is
now in the falco_load_result static methods, so move the text there
and remove the methods here.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add new load_rules methods that return a result object instead of
throwing exceptions on error. The existing load_rules methods call the
new methods internally and continue to throw exceptions on
error/return individual values on success.
The result is returned as a unique_ptr so it can be populated while
loading rules (as a part of the configuration object) and then move()d
to the return value.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Define a falco_load_result abstract class for use in new load_rules
methods. It's abstract so the implementation details in
rule_loader/rule_reader can be hidden from someone who wants to use
the API to load rules and work with a result.
The class defines a set of error codes/warning codes and has static
methods to get a short and long description of each error/warning.
There are virtual methods to access the important parts of a result:
- successful or not
- a string representation of the result, suitable for display to
users. Takes a verbose argument. When verbose is true, the string is
multi-line and has full details, including locations, item names,
etc. When verbose is false, the string is single-line and just
returns error codes.
- a json representation of the result, suitable for automated
parsing/interpretation later.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This allows for native-speed build of docker images, reducing CI time spent in
docker buildx qemu cross build for arm64 up to 10x.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
The only use of it was to include in --support output, which is
redundant as the support output already includes the full contents of
each rules file.
Additionally, it wasn't even being updated after the switch from lua
rules loading to c++ rules
loading (https://github.com/falcosecurity/falco/pull/1966/ or
surrounding PRs).
This will simplify follow-on changes to add a real "result" to rules
loading methods, as there will be fewer API variants to support.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Moreover, updated readme using aarch64 instead of arm64 (same that is used in the badge), and adding "-x86_64" suffix to x86 packages.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Luca Guerra <luca@guerra.sh>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Note that another bump is required before releasing Falco, since this commit uses alpha versions.
Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
Perform the validate_rules action before the load_rules action. This
ensures that *only* the rules files named with -V arguments are
validated.
This fixes https://github.com/falcosecurity/falco/issues/2087.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
In some cases the rule is not triggered when a reverse shell is spawned.
That's because in the rule we are checking that the file descriptor passed
as argument to the dup functions is of type socket and its fd number is "0, 1, or 2"
and the event direction is "enter".
The following event does not trigger the rule: dup2(socket_fd, STDIN_FILENO);
But using the exit event the rule is triggered.
Signed-off-by: Aldo Lacuku <aldo@lacuku.eu>
The Flatcar kernel module build needs to relocate binaries in /host/lib/modules
to run with the host's ld and glibc. While testing with glibc 2.34 that we plan
to introduce soon, we found that the previous dynlinker symlink (ld-xxx.so)
doesn't exist any longer. Update the hostld variable to use a path that is
present in all versions of glibc.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Pre-built kernel modules/eBPF probes for Flatcar use the value of the OS
VERSION_ID field as KERNEL_RELEASE in the filename. A specific kernel release
version does not uniquely identify a Flatcar configuration, because Flatcar is
image-based instead of package-based. Here's a more specific example: the same
kernel version can be part of various Flatcar releases (across channels
alpha/beta/stable) with differences in configuration. This is why we use the
VERSION_ID value during offline builds with driverkit. Flatcar version numbers
are all higher than 1500.0.0, so there is no risk of collision with kernel
version numbers.
When locally building the kernel module on the system, we have access to the
correct kernel build directory at /lib/modules/$(uname -r)/build with the right
configuration and so for that branch, we need to reset KERNEL_RELEASE=$(uname -r).
See also the driverkit PR that introduces a builder for Flatcar:
https://github.com/falcosecurity/driverkit/pull/131
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Relocate necessary tools from the kernel module build system to run using host
dynlinker and libraries, so that compiling falco module on Flatcar works.
Since Flatcar v2983.0.0, Flatcar ships with glibc-2.33, but the
falco-driver-loader container is based on debian:buster and so has a much older
glibc. This prevents some necessary tools within /lib/modules/*/build from
working which causes the falco module to fail to compile using dkms.
To make the tools work, we need to relocate them so we add patchelf to the
falco and local dockerfiles. The relocation is based on the approach done by
the sysdig agent-kmodule build system, but I'm unable to find the source code
for it. The host linker and libs will be found at /host/usr/lib64, so we change
the interpreter and rpath on the tools. The relocation happens on a copy of the
tools which are then bind mounted at the right location. The result allows the
module build to work.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Newest Debian/Ubuntu versions look for this file instead of Release + Release.asc, hitting lots of 404 (and a retry on the old format).
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
They can be pushed with `docker buildx` for various architectures.
Moreover, updated falco-driver-loader to support multiple architectures.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Moreover, add support for aarch64 plugins, even if Falco 0.32 won't be distributed with official arm64 support.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
This updates the engine to comply and work properly with the newly-introduced
interface design.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The filter_ruleset interface its implementation evt_type_index_ruleset
have been modified as follows:
- Only keep track of ruleset ids and not names. The falco engine will take
care of mapping easy-to-remember ruleset names to ruleset ids.
To emphasize this, use ruleset_id everywhere and not ruleset.
Also, make it non-optional.
- Have explicit separate functions to enable/disable rules, instead of a single enable() method combined with a boolean flag.
This does *not* change the falco_engine interface, which has
similar methods, to avoid breaking API changes.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Co-authored-by: Mark Stemm <mark.stemm@gmail.com>
This also fixes a couple of bugs. With the current implementation, the multi-ruleset feature is broken with multiple sources.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This interface will allow us to use different ruleset implementations inside the same engine.
The goal is to define API boundaries that will allow swapping the current evttype-index
ruleset implementation more easily. Key benefits include: smaller component with less responsibilities,
easier substituibility, more testable design, opportunity to adopt different index strategies
depending on the ruleset implementation.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This means that when starting Falco passing to it a folder for its rules, it will properly manage
changes to any file inside the folders, plus any created/deleted file inside it.
Unified list of rules parsing, instead of having it done twice inside cmdline_options and configuration.
Instead, it is done only once, inside load_rules_files.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
When adding an implied "in" comparison to an exception using the
single value form, add it to item, not items.
This fixes#1984.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This include making a coherent use of const, remove private inheritance, and adding virtual destructors.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This involves moving the code in falco_init() into individual files
below app_actions/. falco_init() simply calls app.run() now. When
app.run() returns false, print any erorr. When app.run() sets restart
to true, falco_init() is called again.
app.run() is still inside a catch block to catch any uncaught
exception.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Each file below app_actions/ defines some of the methods declared in
falco::app::application.
Any state that needs to be shared betweeen methods, or between the run
and teardown methods, resides in falco::app::application::state(), so
the moved code stays pretty much as-is, other than replacing stack
variables with member variables in app_state.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Changes to the falco::app::application object to support actions:
- All of the code that was in falco_init is now in methods of
application. (A later commit actually moves the code from falco_init
and into the split-up methods, this commit just declares them).
- Methods return an application::run_result object, which is a tuple
of success/errstr/proceed. proceed=false is used to short circuit
calling methods (think --help, --list, --support, etc.)
- application now has a run() method which runs the methods in an order
that honors any implicit dependencies (e.g. you have to init an
inspector before you open it, you have to do almost everything else
before processing events, etc.)
- There are a few methods devoted to teardown, they are always called
after the group of run methods are called.
- State that needs to be saved between methods, or saved between the
run and teardown functions, is in a
falco::app::application::state object.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Some objects used by falco (falco outputs, falco_formats, etc) were
using raw pointer references, which isn't great.
So convert use of raw pointers (originally passed from falco_init or
functions it called) with shared_ptr, as they are now held in
application state.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
With the split of falco_init into application:: methods, including a
notion of a success/error/proceed result, there is a
more concrete line between runtime errors (e.g. things that throw
exceptions) and errors returned by methods that run the application.
Some of the plugins tests were expecting errors to be returned by
exceptions (e.g. with a leading "Runtime error: and a trailing "
Exiting.").
Now, the errors are just returned directly in application::run(), so
drop the leading and trailing bits in expected test outputs.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
The first warnings we support involve the unsafe comparisons with <NA>, which were present
in the legacy regression tests for PSPs.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
At the same time, this also simplifies the unit test cases by using the SCENARIO construct of catch2,
which allows sharing a setup phases between different unit tests, and removes a bunch of repeated LOC in our case.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Once all rule files have been loaded, and all the rules have been compiled into filters and inserted in the engine rulesets, the loader definitions are maintained in memory without really being used. This commit adds a convenience method to clear the loader state and free-up some memory when engine consumers do not require such information in memory anymore.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The rule_reader class is responsible of parsing the YAML ruleset text and of using the rule_loader
to store the new definition in the internal state. This is a first step towards separating the YAML
reading logic from the rule parsing one. Potentially, this will allow us to read rulesets from another
YAML library or from something different than YAML files too.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The rule_loader is now simply responsible of collecting list/macro/rule definitions and then compiling them as falco_rules. The ruleset file reading code will be moved to another class
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This is a porting of what we had inside the Lua codebase. This now handles the single responsibility
of gathering stats about rule-event matching, and of formatting them to print them to the user.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The function implementation was removed, however it was still defined in the .h header. Moreover,
this will now be required in order to replace its lua equivalent.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
falco_engine::process_event gets called for every inspector event.
Profiling showed that std::map::find takes about 10% of
falco_engine::process_event, and that can easily improved by accessing
the source by index.
Signed-off-by: Angelo Puglisi <angelopuglisi86@gmail.com>
Both the parser.lua and compiler.lua modules are not necessary anymore, because all the logic related
to filter parsing and compilation is handled inside libsinsp now. Accordingly, they have been removed from
the lua-to-cpp.sh scripts. README.md and parse-smoke.sh have been removed since they are not needed anymore:
lpeg is not used by the project, and the smoke tests are implemented in libsisnsp unit test suite.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The lua_filter_helper class is a simple Lua wrapper that can be used in the Lua rule loader to
parse/compile rule filters, and manipulate them to resolve/replace list and macro references.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The Lua parser grabbed from libs chisels is not used anymore, as the compilation logic happen inside the new
filter parser of libsinsp.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This is a first step towards porting the rule filter building logic that is currently implemented in Lua.
filter_macro_resolver uses the newly introduced AST constructs from libsinsp, and
allow manipulating filter ASTs to resolve/replace macro references. This is meant to be used
at boot time by the rule loader (which we still want to maintain implemented in Lua for now).
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
The Lua PEG parser is not longer needed, since we now use the new filter parser implemented
in libsinsp.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This is required due to the plugin API version being bumped to 1.0.0 in the framework after
the recent breaking changes. cloudtrail and json will be switched back to a stable build
once they get released to require the plugin API version with the newest major.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Add new test cases for a rule with an unknown source *and* an
exception, and a macro with an unknown source.
The first results in a rule warning (and no error), and the second
prints an error and skips.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Also skip macros with unknown sources. This matters primarily for
macros related to plugins that have a distinct event source.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
If a rule has an unknown source, *and* has exceptions, loading the
rule will result in an error and not skipping the rule. This is
because exceptions are also validated for unknown fields, and that
occurs before the current check for unknown sources.
The fix is to move the check for unknown sources as soon as the rules
object is read.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
I am co-authoring original authors to keep their credits.
Co-Authored-by: Kris Nova <kris@nivenly.com>
Co-Authored-By: Leonardo Di Donato <leodidonato@gmail.com>
Co-Authored-By: Massimiliano Giovagnoli <massimiliano.giovagnoli.1992@gmail.com>
Co-Authored-By: Jonah Jones <jonahjones094@gmail.com>
Co-Authored-By: Lorenzo Fontana <lo@linux.com>
Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
This adds a new macro `user_known_mount_in_privileged_containers` which
allows the easier user-defined exclusions for the "Mount Launched in
Privileged Container" rule.
This would be cleaner with the exclusions feature, but this feature
is not used in the default ruleset yet, if I understand correctly.
Signed-off-by: Matt Moyer <mmoyer@figma.com>
Update falco's main falco_init() to use a falco::app::application and
falco::app::cmdline_opts object instead of storing all its command
line state in stack variables.
The bulk of the removed code is in usage() (not needed as cxxopt's
help() is self-documenting.) and getopt_long() which is replaced by
app.init(argc, argv).
For the most part, this is simply replacing references to local
variables (e.g. "all_events") to the bound variable inside the
cmdline_opts object (e.g. app.copts().all_events).
There are a few cases where more complex logic was used (output
formats, initializing k8s/mesos with string pointers), and those
changes are still in falco_init().
For the most part, the monolithic parts of falco_init that involve
reading config files, creating the inspector, loading rules, etc are
still present. Those will be addressed in later changes.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
For the most part, replacing getopt() with cxxopts + falco application
had no effect on falco engine/config interfaces. However, there were a
few places where it was wasier to change the interface than add
middleware code that transformed from, for example, vectors to lists.
This commit has those changes.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Fill in an initial falco::app::cmdline_options class using cxxopts
library to hold options:
- falco::app::cmdline_options contains a cxxopts::Options object to
parse options and a cxxopts::ParseResult to hold the result.
- The only meaningful public method is parse() which parses argc/argv
and returns true/false + error.
- The parsed options are all public instance variables of the object
and generally use the same names of the corresponding variables in
the old falco_init(). These variables are all bound to the
corresponding command line option and are updated in parse().
- In a few cases, the command line option does not directly map to a
bound variable (e.g. -b to set buffer format, -p/-pk/-pc to set
extra formatting options, etc.) In these cases the option values are
read after parsing and update the public instance variable.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add a notion of a falco application object. Eventually this will
replace the bulk of falco_init and contain methods to:
- Parse/validate command line options
- Parse/validate falco config
- Initialize prerequsites (inspector, falco engine, webserver, etc)
- Load plugins
- Load/validate rules
- Command/subcommand execution (e.g. --list/--list-fields, or
nothing specified to run "main" loop)
For now, it is only responsible for command line options handling,
which is stubbed out.
Currently, the only public methods are init() to initialize everything
and copts() to access command line options.
Command line options are held in a different class
falco::app::cmdline_opts. application::copts() returns a reference to
that object, which allows access to parsed command line options bound
to various public instance variables.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
We'll use this to better manage the fairly large set of command line
options in self-contained objects instead of a scattering of
individual stack variables.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Replace nearly-identical blocks of code that defined individual custom
targets/custom commands to copy files from source to build dir with
the copy_files_to_build_dir function.
This reduces the number of build targets and speeds up/cleans up the
make output.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Define a cmake function copy_files_to_build_dir(source_files,
targetsuffix) that defines a single custom target and single custom
command to copy the set of source files to
CMAKE_CURRENT_BINARY_DIR. All of the real work is done via cmake -E
copy_if_different.
This function will replace the nearly identical cmake code in several
other directories. This function has the advantage of being a single
target for the set of source files instead of a target per-file.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
I noticed that some external projects were being reconfigured/built
with every make, even though no files in the external project had been
updated.
With some debugging I noticed that git based external projects were
re-running their "update" step every time, and that in turn caused the
configure/build/install steps to re-run as well. (Generally the build
step is a no-op as the Makefile/etc. in the external project is well
formed and doesn't do anything, but the configure/install steps still
run).
It seems related to this cmake bug:
https://gitlab.kitware.com/cmake/cmake/-/issues/19703. In short, the
git update step for an external project does not create any "done"
file that denotes that the files are still up-to-date. Without that
"done" file, the update step is always run, and that in turn causes
the other steps for the external project to re-run as well.
The best way to fix this seems to be to skip the update step by
defining an empty UPDATE_COMMAND. As long as the downloaded code for a
given hash/tag/etc does not change, the update step is unnecessary.
And if we *really* wanted to ensure unchanged dependencies, we would
download our own copies anyway.
Making this change significantly cleans up the falco build to avoid
rebuilding git based external dependencies.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Adds `npm` to `package_mgmt_binaries` for detection of "living off the land" style attacks that utilize NPM pull down additional tooling
Signed-off-by: rileydakota <dakotariley2@gmail.com>
This workaround an issue in libs, targeting Falco 0.31.0.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
New rule to prevent hardlink bypass and symlink rule set to WARNING for consistency
Signed-off-by: Shay Berkovich <sberkovich@blackberry.com>
Co-authored-by: Meera Balsara <mbalsara@blackberry.com>
The `falco_hostnetwork_images` list is unused.
This PR removes it to avoid the warning.
```console
When reading rules content: 1 warnings:
list falco_hostnetwork_images not refered to by any rule/macro/list
```
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
When listing fields with -N (names only), also skip fields with the
EPF_TABLE_ONLY flag. (Skipping fields without -N is handled in libs,
in the as_string() method).
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This fixes the parser introduced in https://github.com/falcosecurity/falco/pull/1792.
Now, nested fields such as `arr[1].subval` are supported, whereas the parser used
to recognize the `.` as an unexpected character.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Instead of having .lua files external to the program responsible for
loading rules, embed the contents of those files into the executable
and load them as strings instead of as files:
Add a cmake custom command below userspace/engine/lua that calls a
bash script lua-to-cpp.sh to generate falco_engine_lua_files.{cpp,hh}
that are compiled into the falco engine library.
The script creates a .cpp file that has const char * symbols for each
file, as well as lists of files that should be loaded when the falco
engine is loaded. There are actually two lists:
- lua_module_strings: these are loaded and also added to the lua
runtime package.preload table, so they are available when lua code
require()s them.
- lua_code_strings: these are loaded *and* evaluated, so the functions
in them are availble to be called from C++.
This simplifies some of the falco_common methods, as there's no need
to keep track of a "main" lua file to load or paths from which the lua
loader should find files for modules, and there's no need to keep
track of an "alternate" lua directory that occurs for debug builds.
Also, there's no need to include any .lua files in the installed
packages, as they're built into the falco binary.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
change LYAML_SRC to LYAML_ROOT, which points to the top source
directory now.
LYAML_LIB and (new) LYAML_LUA_DIR are based relative to that
directory.
There's no install step at all now--the static library and the .lua
files are now used directly from the source tree.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This will distinguish it from rule_loader.lua, which is *not* a module
but lua code with functions that can be called directly.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update json_event_filter_factory::get_fields() to add the new
info (shortdesc, data_type, tags) to field descriptions.
This allows for richer outputs when printing info on the fields.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
With the new implementation of list_fields(), the order of fields
changed slightly. So update the checksum.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Instead of having a falco-specific function to print field info, use
the built-in filter_fieldclass_info::as_string() instead. This is a
better implementation (displays addl info, has better wrapping, wider
output) and having a single implementation allows for consistent
outputs between falco and other potential programs that could use the libs.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Since now, the maximum depth supported to access config fields is two.
This adds support for accessing fields of arbitrary nesting depth.
A formal grammar has been explicited for the regular language representing
the field keys. The accessor methods have been updated accordingly.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This is a change of direction from the current design, that imposes loading
the configuration from file only, and in the object constructor. Instead,
yaml_configuration objects can now be reused ad can load the YAML config
from either file or string. This also makes it easier to unit test this class.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
Signed-off-by: Sai Arigeli <saiharisharigeli@gmail.com>
Return warnings after validation of rule exceptions
Signed-off-by: Sai Arigeli <saiharisharigeli@gmail.com>
Update FALCO_ENGINE_VERSION
Signed-off-by: Sai Arigeli <saiharisharigeli@gmail.com>
This allows defining rules that simply enable/disable already defined rules, like the following:
- rule: A rule enabled by default
enabled: false
- rule: A rule disabled by default
enabled: true
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
When MUSL_OPTIMIZED_BUILD is specified, falco is statically linked under
musl, and can't dlopen() files: see
https://inbox.vuxu.org/musl/20200423162406.GV11469@brightrain.aerifal.cx/T/
So skip listing/loading/testing plugins when MUSL_OPTIMIZED_BUILD is specified.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Test infrastructure and sample confs/rules/traces for plugins
automated tests:
New test cases are in falco_tests_plugins.yaml and cover:
- Listing plugins and fields when plugins are loaded.
- Basic cloudtrail + json plugin on a fake cloudtrail json file and a
sample rule that uses both plugins.
- Conflicts between source/extractor plugins
- Incompatible plugin api
- Wrong plugin path
- Checking for warnings when reading rules with unnown sources (e.g. when plugins are not loaded)
Some test-only plugins written in C are in test/plugins and built on
the fly. (They aren't included in packages of course).
The test framework needed some small changes to handle these tests:
- Add a mode to not check detection counts at all (for --list/--list-plugins)
- addl_cmdline_opts to allow specifying --list/--list-plugins
- Using DOTALL when matching stderr/stdout (allows multi-line matches more easily)
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update the falco binary to add support for plugins.
- Keep track of an "event source", which is initially "syscall" but
changes to the input plugin's source if an source plugin ends up being
loaded.
- New argument --list-plugins will return info on any loaded plugins,
using sinsp_plugin::plugin_infos.
- Create filter/formatter factories for plugins. This ensures that
filterchecks for syscalls are not used for plugins and vice versa.
- Use sinsp_plugin::register_plugin() to load each plugin found in
config. The first source plugin found (if any) calls
engine->add_source withthe source plugin's event source.
- If a second source plugin is found, exit with an error.
- Extractor plugins must be compatible with the event source (usually
the plugin event source, but could be "syscall"). If not, exit with
an error.
- Multiple Extractor plugins are allowed, but they can not have
overlapping compatible event sources. This is mostly to avoid
confusion, but we might change this later.
- After loading plugins, use engine is_plugin_compatible to ensure
that the plugin is compatible with any required_plugin_version blocks
in falco rules.
- Normally falco would log warnings if too many SCAP_TIMEOUT results
were received. These are more expected when using plugins, so only
log these warnings when using syscalls.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
The generic events support already handled most of this, with a
dedicated formatter factory for plugin sources. Just one missing
header include and change the logic slightly for json parsing.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Rules loading changes for plugins:
- parse required_engine_versions from yaml and pass up to rules
loader as a lua table as an additional return value from load_rules().
- c++ rules loader converts to map: plugin -> list of required plugin
versions
- support is_source_valid callback from lua, calls engine method. If
a source is not valid, skip any rules for that source and add a warning.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Mostly plugins are just handled as a new filter/formatter factory with
a new source based on the loaded input plugin, but there are a few
changes at the engine level:
- is_source_valid returns whether a filter/formatter factory exists
for a given source. Will be used by rules loaded to skip rules for
an unknown source.
- the falco engine now holds the required_plugin_version predicates
found in rules files and a method is_plugin_compatible returns whether
a plugin semver is compatible with the predicates in the rules
- Update the falco engine version and fields checksum for plugins
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
These rules can be used when combined with the cloudtrail plugin.
They're installed to /etc/falco like the other rules files.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add a cmake module "plugins" that does the following:
- Downloads/installs the plugins artifacts from a known tag
- Copies the resulting cloudtrail/json shared libraries to
CMAKE_CURRENT_BINARY_DIR/plugins
- Installs them to FALCO_SHARE_DIR/plugins
The default config will define the plugins but they will be disabled
by default.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
It took a while, but we remembered to finish moving the token_bucket
from falco engine to libs. There were 2 copies for a while.
This brings over one change to libs--to have an optional timer
function.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update config code/default falco.yaml to add support for plugins:
- Update config parsing methods to support reading plugin config
objects in a list from yaml.
- The default config defines the cloudtrail/json plugins but does not
give them any actual config for init config/open
params (cloudtrail), or init config (json).
- load_plugins is empty so neither plugin is actually loaded by default.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>-
This moves up the commit to one that has plugins support.
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Loris Degioanni <loris@sysdig.com>
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
When FALCO_VERSION was provided via a CMake variable, the build would
eventually fail because the partial version variables hadn't been
populated. Move the creation of those outside the check of FALCO_VERSION
being set so they also happen when that is provided too.
Contributes-to: #1654
Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
The trace file traces-positive/run-shell-untrusted.scap has an old
execve event number (PPME_SYSCALL_EXECVE_18), which was replaced by
PPME_SYSCALL_EXECVE_19 in 2018.
Given the changes in https://github.com/falcosecurity/libs/pull/94,
these events are now skipped. So change the test to note that *no*
events will be detected.
As a bit of context, event numbers won't be changing any longer--a
change around the same time 298fbde8029020ce3fbddd07e2910b59cc402b8b
allowed for extending existing events to add new parameters instead of
having to define a new event number just to add a new parameter. So
the notion of "old events" should not exist for any event created
after mid-to-late 2018.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
It turns out that the macro inbound_outbound had a logical bug where
joining the beginning and end of the macro with "or" led to the macro
matching all event types by accident.
Most of the time this isn't harmful but it turns out some trace files
will do operations on inet connection fds like "dup", and those get
mistakenly picked up by this macro, as the fd for the event does
happen to be a network connection fd.
This fixes the macro to only match those event types *and* when the fd
is a inet connection fd.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
With the changes in https://github.com/falcosecurity/libs/pull/74,
there isn't any need to warn about the order of operators and the
evt.type field--the set of event types for a filter should be exact
now regardless of the order of operators.
So update tests that were logging those warnings to note that the
warnings won't occur any more.
Also, some tests more accurately *do* note that they have an overly
permissive evttype (e.g. ones related to syscalls, which are uncommon
and are evaluated for all event types) to reflect the new behavior.
Finally, in unit tests create an actual sinsp filter instead of a
gen_event_filter, which is the base class and shouldn't be created
directly.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This makes the output of --list a bit more precise to only include
filter fields and not output fields.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
This step used to be done in the lua rule loading code, but now we can
get it directly from the filters, so do it in falco instead.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update the lua side of rule loading to reflect other changes:
- install_filter renamed to create_filter_obj, and takes just a
lua_parser object created via falco_rules.create_lua_parser() and
uses a single lua callback "filter" instead of separate ones for
syscall/k8s_audit. It can return an error, including about
undefined fields
- is_defined_filter, which used to be local and based on the result of
sinsp_rule_utils.check_for_ignored_syscalls_events, is now a
lua_callback falco_rules.is_defined_field().
- Don't need to pass down sinsp_lua_parser/json_lua_parser now,
creating filters is handled via lua callbacks.
- Checking for ignored syscalls/events is now done in falco itself,
after loading rules.
- add_xxx_filter replaced by add_filter + source.
- Use is_format_valid instead of formats.formatter/formats.free_formatter.
- We don't need the functions in sinsp_rule_utils any longer, so
remove the file and don't import it.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Add a function is_defined_field(source, fldname) that returns whether
a field with name fldname exists for the given event source. This uses
the filter factory to create a filtercheck, and returns true if an
object was created.
This prevents having to push down the entire set of defined fields
before calling load_rules().
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Use the new falco engine interface with support for generic events
instead of event-specific process_xxx_event methods.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Update rules loader to be more general purpose by using factories and
the general purpose engine:
- A lua callback create_lua_parser creates a lua_parser with a filter
object of the right type. The lua parser can then iterate the AST
and populate the filter object.
- Like the falco engine, the rules loader is configured with a list of
factories, and add_filter is now general purpose, taking a source.
Given the fix in https://github.com/falcosecurity/libs/pull/72, there
isn't any need to pass down the entire set of sinsp event
types/syscalls and validate that all filter event types are
valid. That job is now handled by the sinsp filter parsing
code. add_filter now returns the number of event types used by the new
filter, and if that number is excessive the lua code will return a
warning.
Format handling is mostly not handled by the rules loader any more. As
a convienence, there's a new lua callback is_format_valid which takes
a source and output string and uses the right formatter factory to
create a formatter. As long as that doesn't throw an exception, the
format is valid.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Instead of having hard-coded support for syscall/k8s_audit events, use
the notions of filter factories/formatter factories to provide generic
support for events having a given source:
- Within the engine, maps m_filter_factories / m_rulesets /
m_format_factories map from a given source to something that can
create filters, hold filters, and create formatters for a given
source. The hard-coded sinsp_factory/json_factory objects are removed.
- The specific add_xxx_filter/process_xxx_event are general purpose
and take an event source.
- A new method create_formatter() takes a source/output format and
provides a shared_ptr to a formatter than can resolve format
strings. This is used by the falco outputs code.
- In falco main, create the syscall/k8s_audit filter and formatter
factories and pass them to the engine. Later, we might make this
configurable/selective.
With all of the above changes, the falco engine doesn't need a direct
inspector any longer, so remove it.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Make json_event_formatter a generic event formatter by inheriting from
gen_event_formatter and implementing its methods.
Most of the actual work is still done by resolve_format (previously
resolve_tokens, to avoid confusion with sinsp formatter, as it behaves
slightly differently).
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Take advantage of the changes in
https://github.com/falcosecurity/libs/pull/75 to have a
general-purpose way to list fields for a given event source.
in the engine, list_fields() now takes a source, iterates over filter
factories, and calls get_fields() for each factory, printing the results.
list_source_fields now calls the engine regardless of source.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Modify falco_formats to only be responsible for resolving a rule's
output string or coming up with a map of field name->field values from
a given output string.
It relies on the changes in
https://github.com/falcosecurity/libs/pull/77 to use generic
formatters for a given source.
Remove lua bindings to create a formatter/free a formatter. Those were
unused as of the changes in
https://github.com/falcosecurity/falco/pull/1451, so finally remove
them now.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Move the code that splits a json object into a list of k8s audit/json
events out of falco engine and into json_evt.
This, along with other changes, allows the falco engine to be more
general purpose and not directly tied to the notion of syscall vs k8s
audit events.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Modify rulesets to not keep track of the event types for a given set
filter. Instead, using the changes in
https://github.com/falcosecurity/libs/pull/74 event types are returned
directly by the filter.
Within each ruleset, there's a vector that maps from event number to
set of filters that are related to that event number. There's also a
general set of filters for all event types.
run() both indexes into the per-event vector as well as iterate over
the all event types set.
Also, used shared_ptr instead of direct pointers, which matches the
updated interface used by lua_parser. This simplifies the bookkeeping
a bit (no more delete when removing rulesets).
Given these changes, there's no need for a separate
falco_sinsp_ruleset class any longer, so remove it.
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
Description of changes to falcosecurity/libs and /falco to support
plugins to provide events and extract fields from events.
Signed-off-by: Loris Degioanni <loris@sysdig.com>
Co-authored-by: Leonardo Di Donato <leodidonato@gmail.com>
Co-authored-by: Mark Stemm <mark.stemm@gmail.com>
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
The option was added but could not work since MINIMAL_BUILD is not declared in this scope (also not currently needed).
Furthermore, it never took effect since the builder image was never built and pushed. For the same reason, we have not noticed it until now.
Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
added list from the survey that allowed mentions of their name publically in the adopters file.
@jonahjon -- please approve or change any verbiage to adding AWS as contributors with all you and the teams work on PROW and all the contributions thus far.
Signed-off-by: Dan Papandrea <dan.papandrea@sysdig.com>
Also, print out the time of the last processed event in the output
fields of the notification.
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
Falco uses a shared buffer between the kernel and userspace to receive
the events (eg., system call information) in userspace.
Anyways, the underlying libraries can also timeout for various reasons.
For example, there could have been issues while reading an event.
Or the particular event needs to be skipped.
Normally, it's very unlikely that Falco does not receive events consecutively.
Falco is able to detect such uncommon situation.
Here you can configure the maximum number of consecutive timeouts without an event
after which you want Falco to alert.
By default this value is set to 1000 consecutive timeouts without an event at all.
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
The rationale is that in case Falco obtains a consistent number of
consecutive timeouts (in a row) without a valid event, something is
going wrong.
This because, normally, the libs send timeouts to Falco (also) to signal events to discard.
In such cases, which are the majority of cases, `ev` exists and is not
`null`.
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
This fix has two major points in it:
- when `std::stoll` is used in parse_as_int64 handle all the exceptions it
can throw (https://en.cppreference.com/w/cpp/string/basic_string/stol)
- when `process_k8s_audit_event` an eventual exception in it does not
stop the webserver process. This is done by doing a catch all handle
outside it and by logging an error message to the caller as well as in
stderr
Signed-off-by: Lorenzo Fontana <lo@linux.com>
In some cases, it might be useful to know what falco engine version a
given falco binary supports. We already have a --support option that
prints info about the system, config, rules files, etc.
Add a engine_info object, with an engine_version property containing the
falco engine version in falco_engine_version.h. In the output, it looks
like this:
...
"engine_info": {
"engine_version": 8
},
...
Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
2021-04-13 10:49:19 +02:00
619 changed files with 34241 additions and 27720 deletions
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, please read our contributor guidelines in the [CONTRIBUTING.md](CONTRIBUTING.md) file and learn how to compile Falco from source [here](https://falco.org/docs/source).
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, please read our contributor guidelines in the https://github.com/falcosecurity/.github/blob/main/CONTRIBUTING.md file.
2. Please label this pull request according to what type of issue you are addressing.
3. . Please add a release note!
3. Please add a release note!
4. If the PR is unfinished while opening it specify a wip in the title before the actual title, for example, "wip: my awesome feature"
-->
@ -22,11 +21,7 @@
> /kind feature
> If contributing rules or changes to rules, please make sure to also uncomment one of the following line:
> /kind rule-update
> /kind rule-create
> /kind release
<!--
Please remove the leading whitespace before the `/kind <>` you uncommented.
@ -40,12 +35,12 @@ Please remove the leading whitespace before the `/kind <>` you uncommented.
> /area engine
> /area rules
> /area tests
> /area proposals
> /area CI
<!--
Please remove the leading whitespace before the `/area <>` you uncommented.
-->
@ -67,11 +62,13 @@ Fixes #
**Does this PR introduce a user-facing change?**:
<!--
If no, just write "NONE" in the release-note block below.
If yes, a release note is required:
Enter your extended release note in the block below.
If the PR requires additional action from users switching to the new release, prepend the string "action required:".
For example, `action required: change the API interface of the rule engine`.
If NO, just write "NONE" in the release-note block below.
If YES, a release note is required, enter your release note in the block below.
The convention is the same as for commit messages: https://github.com/falcosecurity/.github/blob/main/CONTRIBUTING.md#commit-convention
If the PR introduces non-backward compatible changes, please add a line starting with "BREAKING CHANGE:" and describe what changed.
For example, `BREAKING CHANGE: the API interface of the rule engine has changed`.
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# Details on CodeQL's query packs refer to : https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
This PR may bring feature or behavior changes in the Falco engine and may require the engine version to be bumped.
Please double check **userspace/engine/falco_engine_version.h** file. See [versioning for FALCO_ENGINE_VERSION](https://github.com/falcosecurity/falco/blob/master/RELEASE.md#falco-repo-this-repo).
Known end users with notable contributions to the project include:
* AWS
* IBM
* Red Hat
Falco is being used by numerous other companies, both large and small, to build higher layer products and services. The list includes but is not limited to:
* Equinix Metal
* IEEE
* Lowes
* Reckrut
* Yellow Pepper
* CTx
* Utikal
* Discrete Events
* Agritech Infra
This is a list of production adopters of Falco (in alphabetical order):
* [ASAPP](https://www.asapp.com/) - ASAPP is a pushing the boundaries of fundamental artificial intelligence research. We apply our research into AI-Native® products that make organizations, in the customer experience industry, highly productive, efficient, and effective—by augmenting human activity and automating workflows. We constantly monitor our workloads against different hazards and FALCO helps us extend our threat monitoring boundaries.
@ -8,22 +24,44 @@ This is a list of production adopters of Falco (in alphabetical order):
* [Coveo](https://www.coveo.com/) - Coveo stitches together content and data, learning from every interaction, to tailor every experience using AI to drive growth, satisfy customers and develop employee proficiency. All Falco events are centralized in our SIEM for analysis. Understanding what is running on production servers, and the context around why things are running is even more tricky now that we have further abstractions with containers and orchestration systems. Falco is giving us a good visibility inside containers and complement other Host and Network Intrusion Detection Systems. In a near future, we expect to deploy serverless functions to take action when Falco identifies patterns worth taking action for.
* [Deckhouse](https://deckhouse.io/) - Deckhouse Platform presents to you the opportunity to create homogeneous Kubernetes clusters anywhere and handles comprehensive, automagical management for them. It supplies all the add-ons you need for auto-scaling, observability, security, and service mesh. Falco is used as a part of the [runtime-audit-engine](https://deckhouse.io/documentation/latest/modules/650-runtime-audit-engine/) module to provide threats detection and enforce security compliance out of the box. By pairing with [shell-operator](https://github.com/flant/shell-operator) Falco can be configured by Kubernetes Custom Resources.
* [Fairwinds](https://fairwinds.com/) - [Fairwinds Insights](https://fairwinds.com/insights), Kubernetes governance software, integrates Falco to offer a single pane of glass view into potential security incidents. Insights adds out-of-the-box integrations and rules filter to reduce alert fatigue and improve security response. The platform adds security prevention, detection, and response capabilities to your existing Kubernetes infrastructure. Security and DevOps teams benefit from a centralized view of container security vulnerability scanning and runtime container security.
* [Frame.io](https://frame.io/) - Frame.io is a cloud-based (SaaS) video review and collaboration platform that enables users to securely upload source media, work-in-progress edits, dailies, and more into private workspaces where they can invite their team and clients to collaborate on projects. Understanding what is running on production servers, and the context around why things are running is even more tricky now that we have further abstractions like Docker and Kubernetes. To get this needed visibility into our system, we rely on Falco. Falco's ability to collect raw system calls such as open, connect, exec, along with their arguments offer key insights on what is happening on the production system and became the foundation of our intrusion detection and alerting system.
* [Giant Swarm](https://www.giantswarm.io/) - Giant Swarm manages Kubernetes clusters and infrastructure for enterprises across multiple cloud providers as well as several flavors of on-premises data centers. Our platform provisions and monitors pure "vanilla" Kubernetes clusters which can be augmented with managed solutions to many common Kubernetes challenges, including security. We use Falco for anomaly detection as part of our collection of entirely open-source tools for securing our own clusters, and offer the same capabilities to our customers as part of our [managed security offering](https://docs.giantswarm.io/app-platform/apps/security/).
* [GitLab](https://about.gitlab.com/direction/defend/container_host_security/) - GitLab is a complete DevOps platform, delivered as a single application, fundamentally changing the way Development, Security, and Ops teams collaborate. GitLab Ultimate provides the single tool teams need to find, triage, and fix vulnerabilities in applications, services, and cloud-native environments enabling them to manage their risk. This provides them with repeatable, defensible processes that automate security and compliance policies. GitLab includes a tight integration with Falco, allowing users to defend their containerized applications from attacks while running in production.
* [gVisor](https://gvisor.dev/) - gVisor secures Kubernetes, containers, and workloads via an alternate execution environment that handles system calls in user space, blocking security issues before they reach the underlying host. gVisor provides defense-in-depth, protection against untrusted code execution, and a secure-by-default Kubernetes experience where containers are a security boundary. Falco can be used with gVisor to detect unusual or suspicious activity using its threat detection engine on top of gVisor runtime execution information.
* [League](https://league.com/ca/) - League provides health benefits management services to help employees understand and get the most from their benefits, and employers to provide effective, efficient plans. Falco is used to monitor our deployed services on Kubernetes, protecting against malicious access to containers which could lead to leaks of PHI or other sensitive data. The Falco alerts are logged in Stackdriver for grouping and further analysis. In the future, we're hoping for integrations with Prometheus and AlertManager as well.
* [Logz.io](https://logz.io/) - Logz.io is a cloud observability platform for modern engineering teams. The Logz.io platform consists of three products — Log Management, Infrastructure Monitoring, and Cloud SIEM — that work together to unify the jobs of monitoring, troubleshooting, and security. We empower engineers to deliver better software by offering the world's most popular open source observability tools — the ELK Stack, Grafana, and Jaeger — in a single, easy to use, and powerful platform purpose-built for monitoring distributed cloud environments. Cloud SIEM supports data from multiple sources, including Falco's alerts, and offers useful rules and dashboards content to visualize and manage incidents across your systems in a unified UI.
* [MathWorks](https://mathworks.com) - MathWorks develops mathematical computing software for engineers and scientists. MathWorks uses Falco for Kubernetes threat detection, unexpected application behavior, and maps Falco rules to their cloud infrastructure's security kill chain model. MathWorks presented their Falco use case at [KubeCon + CloudNativeCon North America 2020](https://www.youtube.com/watch?v=L-5RYBTV010).
* [NETWAYS Web Services](https://nws.netways.de/en/) - NETWAYS Web Services provides cloud and managed services tailored to their customers needs. From VPCs to managed databases and Kubernetes clusters, NETWAYS Web Services enables their customers to run infrastructure and applications without worries. Falco plays its part for NETWAYS Managed Services to ensure their platform conforms to ISO 27001 at all times and that their clients' workloads behave as expected by detecting anomalies in real-time.
* [Pocteo](https://pocteo.co) - Pocteo helps with Kubernetes adoption in enterprises by providing a variety of services such as training, consulting, auditing and mentoring. We build CI/CD pipelines the GitOps way, as well as design and run k8s clusters. Pocteo uses Falco as a runtime monitoring system to secure clients' workloads against suspicious behavior and ensure k8s pods immutability. We also use Falco to collect, process and act on security events through a response engine and serverless functions.
* [Preferral](https://www.preferral.com) - Preferral is a HIPAA-compliant platform for Referral Management and Online Referral Forms. Preferral streamlines the referral process for patients, specialists and their referral partners. By automating the referral process, referring practices spend less time on the phone, manual efforts are eliminated, and patients get the right care from the right specialist. Preferral leverages Falco to provide a Host Intrusion Detection System to meet their HIPPA compliance requirements.
* [Preferral](https://www.preferral.com) - Preferral is a HIPAA-compliant platform for Referral Management and Online Referral Forms. Preferral streamlines the referral process for patients, specialists and their referral partners. By automating the referral process, referring practices spend less time on the phone, manual efforts are eliminated, and patients get the right care from the right specialist. Preferral leverages Falco to provide a Host Intrusion Detection System to meet their HIPAA compliance requirements.
* [Qonto](https://qonto.com) - Qonto is a modern banking for SMEs and freelancers. Qonto provides a fully featured business account with a simplified accounting flow. Falco is used by our SecOps team to detect suspicious behaviors in our clusters.
* [Raft](https://goraft.tech) - Raft is a government contractor that offers cloud-native solutions across many different agencies including DoD (Department of Defense), HHS (Health and Human Services), as well as within CFPB (Consumer Finance Protection Bureau). Raft leverages Falco to detect threats in our client's Kubernetes clusters and as a Host Intrusion Detection System. Raft proudly recommends Falco across all our different projects.
* [Replicated](https://www.replicated.com/) - Replicated is the modern way to ship on-prem software. Replicated gives software vendors a container-based platform for easily deploying cloud native applications inside customers' environments to provide greater security and control. Replicated uses Falco as runtime security to detect threats in the Kubernetes clusters which host our critical SaaS services.
* [Secureworks](https://www.secureworks.com/) - Secureworks is a leading worldwide cybersecurity company with a cloud-native security product that combines the power of human intellect with security analytics to unify detection and response across cloud, network, and endpoint environments for improved security operations and outcomes. Our Taegis XDR platform and detection system processes petabytes of security relevant data to expose active threats amongst the billions of daily events from our customers. We are proud to protect our platform’s Kubernetes deployments, as well as help our customers protect their own Linux and container environments, using Falco.
* [Shopify](https://www.shopify.com) - Shopify is the leading multi-channel commerce platform. Merchants use Shopify to design, set up, and manage their stores across multiple sales channels, including mobile, web, social media, marketplaces, brick-and-mortar locations, and pop-up shops. The platform also provides merchants with a powerful back-office and a single view of their business, from payments to shipping. The Shopify platform was engineered for reliability and scale, making enterprise-level technology available to businesses of all sizes. Shopify uses Falco to complement its Host and Network Intrusion Detection Systems.
* [SafeDep](https://safedep.io/) - SafeDep is a open source software supply chain security platform that helps organizations identify and mitigate risks in their dependencies. At its core, SafeDep offers [`vet`](https://github.com/safedep/vet) a free and open source tool for detecting vulnerabilities, malicious code, and quality issues in open source components, while the enterprise offering, SafeDep Cloud, provides centralized control, data aggregation, and advanced features like malware analysis for large-scale deployments across thousands of repositories.
* [Sight Machine](https://www.sightmachine.com) - Sight Machine is the category leader for manufacturing analytics and used by Global 500 companies to make better, faster decisions about their operations. Sight Machine uses Falco to help enforce SOC2 compliance as well as a tool for real time security monitoring and alerting in Kubernetes.
* [Skyscanner](https://www.skyscanner.net) - Skyscanner is the world's travel search engine for flights, hotels and car rentals. Most of our infrastructure is based on Kubernetes, and our Security team is using Falco to monitor anomalies at runtime, integrating Falco's findings with our internal ChatOps tooling to provide insight on the behavior of our machines in production. We also postprocess and store Falco's results to generate dashboards for auditing purposes.
@ -32,6 +70,32 @@ This is a list of production adopters of Falco (in alphabetical order):
* [Swissblock Technologies](https://swissblock.net/) At Swissblock we connect the dots by combining cutting-edge algorithmic trading strategies with in-depth market analysis. We route all Falco events to our control systems, both monitoring and logging. Being able to deeply analyse alerts, we can understand what is running on our Kubernetes clusters and check against security policies, specifically defined for each workload. A set of alarms notifies us in case of critical events, letting us react fast. In the near future we plan to build a little application to route Kubernetes internal events directly to Falco, fully leveraging Falco PodSecurityPolicies analyses.
* [Shapesecurity/F5](https://www.shapesecurity.com/) Shapesecurity defends against application fraud attacks like Account Take Over, Credential Stuffing, Fake Accounts, etc. Required by FedRamp certification, we needed to find a FIM solution to help monitor and protect our Kubernetes clusters. Traditional FIM solutions were not scalable and not working for our environment, but with Falco we found the solution we needed. Falco's detection capabilities have helped us identify anomalous behaviour within our clusters. We leverage Sidekick (https://github.com/falcosecurity/charts/tree/master/falcosidekick) to send Falco alerts to a PubSub which in turn publishes those alerts to our SIEM (SumoLogic)
* [Shapesecurity/F5](https://www.shapesecurity.com/) Shapesecurity defends against application fraud attacks like Account Take Over, Credential Stuffing, Fake Accounts, etc. Required by FedRamp certification, we needed to find a FIM solution to help monitor and protect our Kubernetes clusters. Traditional FIM solutions were not scalable and not working for our environment, but with Falco we found the solution we needed. Falco's detection capabilities have helped us identify anomalous behaviour within our clusters. We leverage Sidekick (https://github.com/falcosecurity/charts/tree/master/falcosidekick) to send Falco alerts to a PubSub which in turn publishes those alerts to our SIEM (SumoLogic)
* [Sysdig](https://www.sysdig.com/) Sysdig originally created Falco in 2016 to detect unexpected or suspicious activity using a rules engine on top of the data that comes from the sysdig kernel system call probe. Sysdig provides tooling to help with vulnerability management, compliance, detection, incident response and forensics in Cloud-native environments. Sysdig Secure has extended Falco to include: a rule library, the ability to update macros, lists & rules via the user interface and API, automated tuning of rules, and rule creation based on profiling known system behavior. On top of the basic Falco rules, Sysdig Secure implements the concept of a "Security policy" that can comprise several rules which are evaluated for a user-defined infrastructure scope like Kubernetes namespaces, OpenShift clusters, deployment workload, cloud regions etc.
* [Sysdig](https://www.sysdig.com/) Sysdig originally created Falco in 2016 to detect unexpected or suspicious activity using a rules engine on top of the data that comes from the sysdig kernel system call driver. Sysdig provides tooling to help with vulnerability management, compliance, detection, incident response and forensics in Cloud-native environments. Sysdig Secure has extended Falco to include: a rule library, the ability to update macros, lists & rules via the user interface and API, automated tuning of rules, and rule creation based on profiling known system behavior. On top of the basic Falco rules, Sysdig Secure implements the concept of a "Security policy" that can comprise several rules which are evaluated for a user-defined infrastructure scope like Kubernetes namespaces, OpenShift clusters, deployment workload, cloud regions etc.
* [Thales Group](https://www.thalesgroup.com) Thales is a global technology leader with more than 81,000 employees on five continents. The Thales Group is investing in digital and “deep tech” innovations – Big Data, artificial intelligence, connectivity, cybersecurity and quantum technology – to build a future we can all trust. In the past few years, the Cloud-Native paradigms and its frameworks and tools have challenged the way applications and services are developed, delivered, and instantiated. All sorts of services are container-based workloads managed by higher level layers of orchestration such as the Kubernetes environment. Thales is committed to develop Cloud-Native services and to provide its customers with security features that ensure their applications and services are protected against cyber threats. Falco is a framework that can help Thales' products and services reach the level of trust, security and safety our clients need.
* [Thought Machine](https://www.thoughtmachine.net) Thought Machine builds Vault Core and Vault Payments: cloud-native core and payments technology enabling banks and fintechs to remain competitive and flourish into the future. Vault Core and Vault Payments are the foundation layer of a bank's technology stack. They can run any bank, any product, and any payment set. Thought Machine uses Falco to perform cloud agnostic real time detections of suspicious container behaviour.
* [Tulip Retail](https://tulip.com) Tulip Retail uses Falco to monitor container activity in our environments. It's numerous integration points, easy deployment and easily customizable rules were the main reasons we chose Falco.
* [Vinted](https://vinted.com/) Vinted uses Falco to continuously monitor container activities, identifying security threats, and ensuring compliance. The container-native approach, rule-based real-time threat detection, community support, extensibility, and compliance capabilities are the main factors why we chose it to enhance Vinted Kubernetes security. Falco Sidekick is used to send critical and warning severity alerts to our incident management solution (RTIR).
* [Xenit AB](https://xenit.se/contact/) Xenit is a growth company with services within cloud and digital transformation. We provide an open-source Kubernetes framework that we leverage to help our customers get their applications to production as quickly and as securely as possible. We use Falco's detection capabilities to identify anomalous behaviour within our clusters in both Azure and AWS.
* [Yahoo! JAPAN](https://www.yahoo.co.jp/) Yahoo! JAPAN is a leading company of internet in Japan. We build an AI Platform in our private cloud and provide it to scientists in our company. AI Platform is a multi-tenant Kubernetes environment and more flexible, faster, more efficient Machine Learning environment. Falco is used to detect unauthorized commands and malicious access and our AI Platform is monitored and alerted by Falco.
## Projects that use Falco libs
* [R6/Phoenix](https://r6security.com/) is an attack surface protection company that uses moving target defense to provide fully automated, proactive and devops friendly security to its customers. There are a set of policies you can add to enable the moving target defense capabilities. Some of them are triggered by a combination of Falco's findings. You can kill, restart and rename pods according to the ever changing policies.
* [SysFlow](https://sysflow.io) SysFlow is a cloud-native system telemetry framework that focuses on data abstraction, behavioral analytics, and noise reduction. At its core, SysFlow exposes a compact open telemetry format that records workload behaviors by connecting event and flow representations of process control flows, file interactions, and network communications. The resulting abstraction encodes a graph structure that enables provenance reasoning on host and container environments, and fast retrieval of security-relevant information.
* [StackRox](https://stackrox.io) is the industry’s first Kubernetes-native security platform enabling organizations to build, deploy, and run cloud-native applications securely. The platform works with Kubernetes environments and integrates with DevOps and security tools, enabling teams to operationalize and secure their supply chain, infrastructure, and workloads. StackRox aims to harness containerized applications’ development speed while giving operations and security teams greater context and risk profiling. StackRox leverages cloud-native principles and declarative artifacts to automate DevSecOps best practices.
* [Wireshark](https://www.wireshark.org) is the world's most powerful and popular network protocol analyzer. The Wireshark team is combining Wireshark's features and Falco libs to create Logray, a cloud and system log analyzer with advanced filtering, capture, and scripting capabilities.
## Adding a name
If you would like to add your name to this file, submit a pull request with your change.
This document introduces the coding style that will be applied in this repository.
This coding style involves all the following files: `.c`, `.h`, `.cpp`, `.cmake`, `CMakeLists.txt`. To enforce it we rely on two main tools:
1. `clang-format` version `18.1.8`.
2. `cmake-format` version `0.6.13`.
> __Please note__: tools versions are important! Different versions will enforce slightly different changes on the code. For example `clang-format-18` will produce a slightly different output respect to `clang-format-17` always respecting the imposed style.
The coding style is expressed through the 2 configuration file that you find in this repo: `.clang-format`, `.cmake-format.json`.
### Enforce the style locally
There are many ways to enforce the style locally, here we will describe two of them:
1. Use `pre-commit` framework.
2. Use the repo `Makefile`.
#### 1.Pre-commit framework (suggested if you don't have the 2 tools already installed on your machine)
The `pre-commit` framework allows you to automatically install different `git-hooks` that will run at every new commit. More precisely, if you use the `.pre-commit-config.yaml` in this repo you will install 3 different hooks:
1. The `clang-format` hook: this is a `pre-commit` git hook that runs `clang-format` on your staged changes.
2. The `cmake-format` hook: this is a `pre-commit` git hook that runs `cmake-format` on your staged changes.
3. The `DCO signed-off` hook: this is a `pre-commit-msg` git hook that adds the `DCO` on your commit if not present. This hook is not strictly related to the coding style so we will talk about it in a separate section: [Add DCO signed-off to your commits](#add-dco-signed-off-to-your-commits).
Now let's see what we need to use `pre-commit` framework.
##### Step 1
Install `pre-commit` framework following the [official documentation](https://pre-commit.com/#installation).
> __Please note__: you have to follow only the "Installation" section.
##### Step 2
Once you have installed `pre-commit`, you don't need to install anything else! This is the good point of using a framework like `pre-commit`, all the tools necessary to format your code will be directly managed by the framework. But in order to be ready, you need to install the git hooks in your local repo.
This simple command allows you to install the two `pre-commit` git hooks, `clang-format` and `cmake-format`.
If you want to install also the `pre-commit-msg` git hook for the DCO you have to type the following command, but be sure to have configured all you need as said in the [dedicated section]((#add-dco-signed-off-to-your-commits))
In order to use the repo `Makefile`, you need to install on your local machine the two aforementioned tools:
__clang-format v18.1.8__
One of the easiest ways to install `clang-format` could be directly downloading its static binary from [here](https://github.com/muttleyxd/clang-tools-static-binaries).
There are other ways for example you can download the package for your distro or you can also build it from sources.
__cmake-format v0.6.13__
To install `cmake-format` you can follow the official documentation [here](https://cmake-format.readthedocs.io/en/latest/installation.html).
> __NOTE__: Please check the versions of the two tool with `clang-format --version` and `cmake-format --version`.
##### Step 2
Once you have installed the __right__ versions of the 2 tools, you can simply type `make format-all` from the root directory of the project (`/libs`) to format all your code according to the coding style.
Remember to do that before submitting a new patch upstream! 😁
#### Other solutions
Obviously, you can also install the 2 tools locally and enable some extension of your favorite IDE (like `VScode`) to format your code every time you save your files!
## Add DCO signed-off to your commits 🔏
### Introduction
Another requirement for contributing to the `libs` repository, is applying the [DCO](https://cert-manager.io/docs/contributing/sign-off/) to every commit you want to push upstream.
Before doing this you have to configure your git user `name` and `email` if you haven't already done it. To check your actual `name` and `email` type:
```bash
git config --get user.name
git config --get user.email
```
If they are correct you have done, otherwise, you have to set them:
>__Please note__: If you have problems in doing this you can read the full documentation [here](https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git).
### Enforce the DCO locally
Now you are ready to sign your commits! You have two main ways to do this:
1. Manually with `git` tool.
2. Use the `pre-commit-msg` hook quoted before.
### Manually
To do this you just need to remember the `-s` while performing your commits:
```bash
git commit -s
```
or with the inline message:
```bash
git commit -s -m "my first commit"
```
### Use `pre-commit` hook
Here if you have already added the hook in the [previous section](#step-2), you have to do nothing otherwise you have to simply install the DCO hook with:
And you have done! Now you don't have to remember the `-s` option every time you commit something, the DCO hook will automatically add the DCO if you forget it! 😄
## Some best practices 📏
### Class variables
To know whether a variable belongs to a `class` or a `function`, we start member variables with `m_`.
Example:
```c
public int32_t m_counter;
```
### Global variables
To know whether the variable is global or not, we start globals with `g_`.
Example:
```c
int g_nplugins;
```
### Capitalization
The naming convention is camel-cased "Unix" style, i.e. always lower case. Words are separated by underscores.
Example:
```c
int32_t g_global_bean_counter;
int32_t count_beans();
```
and not,
```c
int32_t GlobalBeanCounter;
int32_t CountBeans();
```
### Packed Structures
Packed structures should use the GCC and MSVC-style supported `pragma`:
Example:
```c
#pragma pack(push,1)
struct frame_control
{
struct fields....
};
#pragma pack(pop)
```
### 64-bit constants
Put an `LL` at the end of your `64-bit` constants. Without the `LL`, some platform compilers try to interpret the constant on the right-hand side as a `long integer` instead of a `long long` and this could lead to an error at building time.
[Falco](https://falco.org/) is a cloud native runtime security tool for Linux operating systems. It is designed to detect and alert on abnormal behavior and potential security threats in real-time.
Read the [change log](CHANGELOG.md).
At its core, Falco is a kernel monitoring and detection agent that observes events, such as syscalls, based on custom rules. Falco can enhance these events by integrating metadata from the container runtime and Kubernetes. The collected events can be analyzed off-host in SIEM or data lake systems.
<!--
Badges in the following table are constructed by using the
Falco, originally created by [Sysdig](https://sysdig.com), is a **graduated project** under the [Cloud Native Computing Foundation](https://cncf.io) (CNCF) used in production by various [organisations](https://github.com/falcosecurity/falco/blob/master/ADOPTERS.md).
Parameters are configured for fetching packages from S3 before
(filtered by prefix, sorted in ascending order) and for picking
the latest package by using an XPath selector after.
For detailed technical information and insights into the cyber threats that Falco can detect, visit the official [Falco](https://falco.org/) website.
- Common query parameters:
For comprehensive information on the latest updates and changes to the project, please refer to the [Change Log](CHANGELOG.md).
color=#300aec7
style=flat-square
label=Falco
## The Falco Project
- DEB packages parameters:
The Falco Project codebase is maintained under the [falcosecurity GitHub organization](https://github.com/falcosecurity). The primary repository, [falcosecurity/falco](https://github.com/falcosecurity/falco), holds the source code for the Falco binary, while other sub-projects are hosted in dedicated repositories. This approach of isolating components into specialized repositories enhances modularity and focused development. Notable [core repositories](https://github.com/falcosecurity/evolution?tab=readme-ov-file#core) include:
- [falcosecurity/libs](https://github.com/falcosecurity/libs): This repository hosts Falco's core libraries, which constitute the majority of the binary’s source code and provide essential features, such as kernel drivers.
- [falcosecurity/rules](https://github.com/falcosecurity/rules): It contains the official ruleset for Falco, offering pre-defined detection rules for various security threats and abnormal behaviors.
- [falcosecurity/plugins](https://github.com/falcosecurity/plugins): This repository supports integration with external services through plugins that extend Falco's capabilities beyond syscalls and container events, with plans for evolving specialized functionalities in future releases.
- [falcosecurity/falcoctl](https://github.com/falcosecurity/falcoctl): A command-line utility designed for managing and interacting with Falco.
- [falcosecurity/charts](https://github.com/falcosecurity/charts): This repository provides Helm charts for deploying Falco and its ecosystem, simplifying the installation and management process.
- RPM packages parameters:
For further insights into our repositories and additional details about our governance model, please visit the official hub of The Falco Project: [falcosecurity/evolution](https://github.com/falcosecurity/evolution).
If you're new to Falco, begin your journey with our [Getting Started](https://falco.org/docs/getting-started/) guide. For production deployments, please refer to our comprehensive [Setup](https://falco.org/docs/setup/) documentation.
As final recommendations before deploying Falco, verify environment compatibility, define your detection goals, optimize performance, choose the appropriate build, and plan for SIEM or data lake integration to ensure effective incident response.
Notes:
- if more than 1000 items are present under as S3 prefix,
the actual latest package will be not picked;
see https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html
- for `-dev` packages, the S3 prefix is modified accordingly
- finally, all parameters are URL encoded and appended to the badge endpoint
### Demo Environment
-->
A demo environment is provided via a docker-compose file that can be started on a docker host which includes falco, falcosidekick, falcosidekick-ui and its required redis database. For more information see the [docker-compose section](docker/docker-compose/)
To get involved with the Falco Project please visit the [Community](https://github.com/falcosecurity/community) repository to find more information and ways to get involved.
The Falco Project, originally created by [Sysdig](https://sysdig.com), is an incubating [CNCF](https://cncf.io) open source cloud native runtime security tool.
Falco makes it easy to consume kernel events, and enrich those events with information from Kubernetes and the rest of the cloud native stack.
Falco has a rich set of security rules specifically built for Kubernetes, Linux, and cloud-native.
If a rule is violated in a system, Falco will send an alert notifying the user of the violation and its severity.
### Installing Falco
If you would like to run Falco in **production** please adhere to the [official installation guide](https://falco.org/docs/getting-started/installation/).
| Helm | [Chart Repository](https://github.com/falcosecurity/charts/tree/master/falco#introduction) | The Falco community offers regular helm chart releases. |
| Minikube | [Tutorial](https://falco.org/docs/getting-started/third-party/#minikube) | The Falco driver has been baked into minikube for easy deployment. |
| Kind | [Tutorial](https://falco.org/docs/getting-started/third-party/#kind) | Running Falco with kind requires a driver on the host system. |
| GKE | [Tutorial](https://falco.org/docs/getting-started/third-party/#gke) | We suggest using the eBPF driver for running Falco on GKE. |
### Developing
Falco is designed to be extensible such that it can be built into cloud-native applications and infrastructure.
Falco has a [gRPC](https://falco.org/docs/grpc/) endpoint and an API defined in [protobuf](https://github.com/falcosecurity/falco/blob/master/userspace/falco/outputs.proto).
The Falco Project supports various SDKs for this endpoint.
Falco can detect and alert on any behavior that involves making Linux system calls.
Falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process.
For example, Falco can easily detect incidents including but not limited to:
- A shell is running inside a container or pod in Kubernetes.
- A container is running in privileged mode, or is mounting a sensitive path, such as `/proc`, from the host.
- A server process is spawning a child process of an unexpected type.
- Unexpected read of a sensitive file, such as `/etc/shadow`.
- A non-device file is written to `/dev`.
- A standard system binary, such as `ls`, is making an outbound network connection.
- A privileged pod is started in a Kubernetes cluster.
### Documentation
The [Official Documentation](https://falco.org/docs/) is the best resource to learn about Falco.
### Join the Community
To get involved with The Falco Project please visit [the community repository](https://github.com/falcosecurity/community) to find more.
If you have any questions about Falco or contributing, do not hesitate to file an issue or contact the Falco maintainers and community members for assistance.
How to reach out?
- Join the #falco channel on the [Kubernetes Slack](https://slack.k8s.io)
- [Join the Falco mailing list](https://lists.cncf.io/g/cncf-falco-dev)
- [Read the Falco documentation](https://falco.org/docs/)
- Join the [#falco](https://kubernetes.slack.com/messages/falco) channel on the [Kubernetes Slack](https://slack.k8s.io).
- Join the [Falco mailing list](https://lists.cncf.io/g/cncf-falco-dev).
- File an [issue](https://github.com/falcosecurity/falco/issues) or make feature requests.
## Commitment to Falco's Own Security
Full reports of various security audits can be found [here](./audits/).
In addition, you can refer to the [falco](https://github.com/falcosecurity/falco/security) and [libs](https://github.com/falcosecurity/libs/security) security sections for detailed updates on security advisories and policies.
To report security vulnerabilities, please follow the community process outlined in the documentation found [here](https://github.com/falcosecurity/.github/blob/main/SECURITY.md).
## Building
For comprehensive, step-by-step instructions on building Falco from source, please refer to the [official documentation](https://falco.org/docs/developer-guide/source/).
## Testing
<details>
<summary>Expand Testing Instructions</summary>
Falco's [Build Falco from source](https://falco.org/docs/developer-guide/source/) is the go-to resource to understand how to build Falco from source. In addition, the [falcosecurity/libs](https://github.com/falcosecurity/libs) repository offers additional valuable information about tests and debugging of Falco's underlying libraries and kernel drivers.
Here's an example of a `cmake` command that will enable everything you need for all unit tests of this repository:
Optionally, build the driver of your choice and test run the Falco binary to perform manual tests.
Lastly, The Falco Project has moved its Falco regression tests to [falcosecurity/testing](https://github.com/falcosecurity/testing).
### Contributing
</details>
See the [CONTRIBUTING.md](https://github.com/falcosecurity/.github/blob/master/CONTRIBUTING.md).
</br>
### Security Audit
## How to Contribute
A third party security audit was performed by Cure53, you can see the full report [here](./audits/SECURITY_AUDIT_2019_07.pdf).
Please refer to the [Contributing](https://github.com/falcosecurity/.github/blob/main/CONTRIBUTING.md) guide and the [Code of Conduct](https://github.com/falcosecurity/evolution/blob/main/CODE_OF_CONDUCT.md) for more information on how to contribute.
### Reporting security vulnerabilities
## FAQs
Please report security vulnerabilities following the community process documented [here](https://github.com/falcosecurity/.github/blob/master/SECURITY.md).
### Why is Falco in C++ rather than Go or {language}?
### License Terms
<details>
<summary>Expand Information</summary>
1. The first lines of code at the base of Falco were written some time ago, where Go didn't yet have the same level of maturity and adoption as today.
2. The Falco execution model is sequential and mono-thread due to the statefulness requirements of the tool, and so most of the concurrency-related selling points of the Go runtime would not be leveraged at all.
3. The Falco code deals with very low-level programming in many places (e.g. some headers are shared with the eBPF probe and the Kernel module), and we all know that interfacing Go with C is possible but brings tons of complexity and tradeoffs to the table.
4. As a security tool meant to consume a crazy high throughput of events per second, Falco needs to squeeze performance in all hot paths at runtime and requires deep control on memory allocation, which the Go runtime can't provide (there's also garbage collection involved).
5. Although Go didn't suit the engineering requirements of the core of Falco, we still thought that it could be a good candidate for writing Falco extensions through the plugin system. This is the main reason we gave special attention and high priority to the development of the plugin-sdk-go.
6. Go is not a requirement for having statically-linked binaries. In fact, we provide fully-static Falco builds since few years. The only issue with those is that the plugin system can't be supported with the current dynamic library model we currently have.
7. The plugin system has been envisioned to support multiple languages, so on our end maintaining a C-compatible codebase is the best strategy to ensure maximum cross-language compatibility.
8. In general, plugins have GLIBC requirements/dependencies because they have low-level C bindings required for dynamic loading. A potential solution for the future could be to also support plugin to be statically-linked at compilation time and so released as bundled in the Falco binary. Although no work started yet in this direction, this would solve most issues you reported and would provide a totally-static binary too. Of course, this would not be compatible with dynamic loading anymore, but it may be a viable solution for our static-build flavor of Falco.
9. Memory safety is definitely a concern and we try our best to keep an high level of quality even though C++ is quite error prone. For instance, we try to use smart pointers whenever possible, we build the libraries with an address sanitizer in our CI, we run Falco through Valgrind before each release, and have ways to stress-test it to detect performance regressions or weird memory usage (e.g. https://github.com/falcosecurity/event-generator). On top of that, we also have third parties auditing the codebase by time to time. None of this make a perfect safety standpoint of course, but we try to maximize our odds. Go would definitely make our life easier from this perspective, however the tradeoffs never made it worth it so far due to the points above.
10. The C++ codebase of falcosecurity/libs, which is at the core of Falco, is quite large and complex. Porting all that code to another language would be a major effort requiring lots of development resource and with an high chance of failure and regression. As such, our approach so far has been to choose refactors and code polishing instead, up until we'll reach an optimal level of stability, quality, and modularity, on that portion of code. This would allow further developments to be smoother and more feasibile in the future.
</details>
</br>
### What's next for Falco?
Stay updated with Falco's evolving capabilities by exploring the [Falco Roadmap](https://github.com/orgs/falcosecurity/projects/5), which provides insights into the features currently under development and planned for future releases.
## License
Falco is licensed to you under the [Apache 2.0](./COPYING) open source license.
Our release process is mostly automated, but we still need some manual steps to initiate and complete it.
Changes and new features are grouped in [milestones](https://github.com/falcosecurity/falco/milestones), the milestone with the next version represents what is going to be released.
## Overview
A release happens every two months ([as per community discussion](https://github.com/falcosecurity/community/blob/master/meeting-notes/2020-09-30.md#agenda)), and we need to assign owners for each (usually we pair a new person with an experienced one). Assignees and the due date are proposed during the [weekly community call](https://github.com/falcosecurity/community). Note that hotfix releases can happen as soon as it is needed.
This document provides the process to create a new Falco release. In addition, it provides information about the versioning of the Falco components. At a high level each Falco release consists of the following main components:
Finally, on the proposed due date the assignees for the upcoming release proceed with the processes described below.
- Falco binary (userspace), includes `modern_bpf` driver object code (kernel space) starting with Falco 0.34.x releases
- Falco kernel driver object files, separate artifacts for `kmod` and `bpf` drivers, not applicable for `modern_bpf` driver (kernel space)
- Option 1: Kernel module (`.ko` files)
- Option 2: eBPF (`.o` files)
- Falco config and rules `.yaml` files (userspace)
- Falco plugins (userspace - optional)
> Note: Starting with Falco 0.34.x releases, the Falco userspace binary includes the `modern_bpf` driver object code during the linking process. This integration is made possible by the CO-RE (Compile Once - Run Everywhere) feature of the modern BPF driver. CO-RE allows the driver to function on kernels that have backported BTF (BPF Type Format) support or have a kernel version >= 5.8. For the older `kmod` and `bpf` drivers, separate artifacts are released for the kernel space. This is because these drivers need to be explicitly compiled for the specific kernel release, using the exact kernel headers. This approach ensures that Falco can support a wide range of environments, including multiple kernel versions, distributions, and architectures. (see `libs` [driver - kernel version support matrix](https://github.com/falcosecurity/libs#drivers-officially-supported-architectures)).
The Falco Project manages the release of both the Falco userspace binary and pre-compiled Falco kernel drivers for the most popular kernel versions and distros. The build and publish process is managed by the [test-infra](https://github.com/falcosecurity/test-infra) repo.
The Falco userspace executable includes bundled dependencies, so that it can be run from anywhere.
Falco publishes all sources, enabling users to audit the project's integrity and build kernel drivers for custom or unsupported kernels/distributions, specifically for non-modern BPF drivers (see [driverkit](https://github.com/falcosecurity/driverkit) for more information).
Finally, the release process follows a transparent process described in more detail in the following sections and the official [Falco guide and documentation](https://falco.org/) provide rich information around building, installing and using Falco.
### Falco Binaries, Rules and Sources Artifacts - Quick Links
The Falco project publishes all sources and the Falco userspace binaries as GitHub releases.
- `tgz`, `zip` source code, each ruleset is tagged separately in a mono-repo fashion, see the [rules release guidelines](https://github.com/falcosecurity/rules/blob/main/RELEASE.md)
Alternatively Falco binaries or plugins can be downloaded from the Falco Artifacts repo.
> Note: This section specifically applies to non-modern BPF drivers.
The Falco Project publishes all drivers for each release for popular kernel versions / distros and `x86_64` and `aarch64` architectures to the Falco project's managed Artifacts repo. The Artifacts repo follows standard directory level conventions. The respective driver object file is prefixed by distro and named / versioned by kernel release - `$(uname -r)`. Pre-compiled drivers are released with a [best effort](https://github.com/falcosecurity/falco/blob/master/proposals/20200818-artifacts-storage.md#notice) notice. This is because gcc (`kmod`) and clang (`bpf`) compilers sometimes fail to build the artifacts for a specific kernel version. More details around driver versioning and driver compatibility are provided in the [Falco Components Versioning](#falco-components-versioning) section. Short preview: If you use the standard Falco setup leveraging driver-loader, [driver-loader script](https://github.com/falcosecurity/falco/blob/master/scripts/falco-driver-loader) will fetch the kernel space artifact (object file) corresponding to the default `DRIVER_VERSION` Falco was shipped with.
- Option 1: Kernel module (`.ko` files) - all under same driver version directory
- Option 2: eBPF (`.o` files) - all under same driver version directory
### Timeline
Falco follows a release schedule of three times per year, with releases expected at the end of January, May, and September. Hotfix releases are issued as needed.
Changes and new features are organized into [milestones](https://github.com/falcosecurity/falco/milestones). The milestone corresponding to the next version represents the content that will be included in the upcoming release.
### Procedures
The release process is mostly automated, requiring only a few manual steps to initiate and complete.
Moreover, we assign owners for each release (typically pairing a new person with an experienced one). Assignees and due dates for releases are proposed during the [community call](https://github.com/falcosecurity/community).
At a high level each Falco release needs to follow a pre-determined sequencing of releases and build order:
Assignees are responsible for creating a Falco GitHub issue to track the release tasks and monitor the progress of the release. This issue serves as a central point for communication and provides updates on the release dates. You can refer to the [Falco v0.35 release](https://github.com/falcosecurity/falco/issues/2554) or [Libs Release (0.11.0+5.0.1+driver)](https://github.com/falcosecurity/libs/issues/1092) issues as examples/templates for creating the release issue.
Finally, on the proposed due date, the assignees for the upcoming release proceed with the processes described below.
## Pre-Release Checklist
Before cutting a release we need to do some homework in the Falco repository. This should take 5 minutes using the GitHub UI.
Before proceeding with the release, make sure to complete the following preparatory steps, which can be easily done using the GitHub UI:
### 1. Release notes
- Find the previous release date (`YYYY-MM-DD`) by looking at the [Falco releases](https://github.com/falcosecurity/falco/releases)
- Double-check, by using the following filters, if there is any closed issue/merge PR with no milestone assigned:
- Assign any issue/PR identified in the previous point to the milestone corresponding to the currently undergoing release
- Check the release note block of every PR matching the `is:pr is:merged closed:>YYYY-MM-DD` [filter](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Amerged+closed%3A%3EYYYY-MM-DD)
- Ensure the release note block follows the [commit convention](https://github.com/falcosecurity/falco/blob/master/CONTRIBUTING.md#commit-convention), otherwise fix its content
- Ensure the release note block follows the [commit convention](https://github.com/falcosecurity/.github/blob/master/CONTRIBUTING.md#commit-convention), otherwise fix its content
- If the PR has no milestone, assign it to the milestone currently undergoing release
- Check issues without a milestone (using [is:pr is:merged no:milestone closed:>YYYY-MM-DD](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Amerged+no%3Amilestone+closed%3A%3EYYYY-MM-DD) filter) and add them to the milestone currently undergoing release
- Double-check that there are no more merged PRs without the target milestone assigned with the `is:pr is:merged no:milestone closed:>YYYY-MM-DD` [filters](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Amerged+no%3Amilestone+closed%3A%3EYYYY-MM-DD), if any, fix them
### 2. Milestones
- Move the [tasks not completed](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Aopen) to a new minor milestone
### 3. Release PR
### 3. Release branch
Assuming we are releasing a non-patch version (like: Falco 0.34.0), a new release branch needs to be created.
Its naming will be `release/M.m.x`; for example: `release/0.34.x`.
The same branch will then be used for any eventual cherry pick for patch releases.
For patch releases, instead, the `release/M.m.x` branch should already be in place; no more steps are needed.
Double-check that any PR that should be part of the tag has been cherry-picked from master!
### 4. Release PR
The release PR is meant to be made against the respective `release/M.m.x` branch, **then cherry-picked on master**.
- Double-check if any hard-coded version number is present in the code, it should be not present anywhere:
- If any, manually correct it then open an issue to automate version number bumping later
- Versions table in the `README.md` updates itself automatically
- Generate the change log using [rn2md](https://github.com/leodido/rn2md):
- In case `rn2md` emits error try to generate an GitHub OAuth access token and provide it with the `-t` flag
- Add the latest changes on top the previous `CHANGELOG.md`
- Submit a PR with the above modifications
- Await PR approval
- Close the completed milestone as soon as the PR is merged
- Close the completed milestone as soon as the PR is merged into the release branch
- Cherry pick the PR on master too
## Publishing Pre-Releases (RCs and tagged development versions)
Core maintainers and/or the release manager can decide to publish pre-releases at any time before the final release
is live for development and testing purposes.
The prerelease tag must be formatted as `M.m.p-r` where `r` is the prerelease version information (e.g. `0.35.0-rc1`.)
To do so:
- [Draft a new release](https://github.com/falcosecurity/falco/releases/new)
- Use `M.m.p-r` both as tag version and release title.
- Check the "Set as a pre-release" checkbox and make sure "Set as the latest release" is unchecked
- It is recommended to add a brief description so that other contributors will understand the reason why the prerelease is published
- Publish the prerelease!
- The release pipeline will start automatically. Packages will be uploaded to the `-dev` bucket and container images will be tagged with the specified tag.
In order to check the status of the release pipeline click on the [GitHub Actions tab](https://github.com/falcosecurity/falco/actions?query=event%3Arelease) in the Falco repository and filter by release.
## Release
Now assume `x.y.z` is the new version.
Assume `M.m.p` is the new version.
### 1. Create a tag
- Once the release PR has got merged, and the CI has done its job on the master, git tag the new release
```
git pull
git checkout master
git tag x.y.z
git push origin x.y.z
```
> **N.B.**: do NOT use an annotated tag
- Wait for the CI to complete
### 2. Update the GitHub release
### 1. Create the release with GitHub
- [Draft a new release](https://github.com/falcosecurity/falco/releases/new)
- Use `x.y.z` both as tag version and release title
- Use the following template to fill the release description:
```
<!-- Substitute x.y.z with the current release version -->
- Use `M.m.p` both as tag version and release title
- Do NOT fill body, since it will be autogenerated by the [github release workflow](.github/workflows/release.yaml)
- Publish the release!
- The release pipeline will start automatically upon publication and all packages and container images will be uploaded to the stable repositories.
| deb | [](https://download.falco.org/packages/deb/stable/falco-x.y.z-x86_64.deb) |
In order to check the status of the release pipeline click on the [GitHub Actions tab](https://github.com/falcosecurity/falco/actions?query=event%3Arelease) in the Falco repository and filter by release.
For each release we archive the meeting notes in git for historical purposes.
- The notes from the Falco meetings can be [found here](https://hackmd.io/6sEAlInlSaGnLz2FnFz21A).
- The notes from the Falco meetings can be [found here](https://hackmd.io/3qYPnZPUQLGKCzR14va_qg).
- Note: There may be other notes from working groups that can optionally be added as well as needed.
- Add the entire content of the document to a new file in [github.com/falcosecurity/community/tree/master/meeting-notes](https://github.com/falcosecurity/community/tree/master/meeting-notes) as a new file labeled `release-x.y.z.md`
- Add the entire content of the document to a new file in [github.com/falcosecurity/community/tree/main/meeting-notes](https://github.com/falcosecurity/community/tree/main/meeting-notes) as a new file labeled `release-M.m.p.md`
- Open up a pull request with the new change.
@ -104,5 +170,47 @@ For each release we archive the meeting notes in git for historical purposes.
Announce the new release to the world!
- IFF the ongoing release introduces a **new minor version**, [archive a snapshot of the Falco website](https://github.com/falcosecurity/falco-website/blob/master/release.md#documentation-versioning)
- Publish a blog on [Falco website](https://github.com/falcosecurity/falco-website) ([example](https://github.com/falcosecurity/falco-website/blob/master/content/en/blog/falco-0-28-1.md))
- Send an announcement to cncf-falco-dev@lists.cncf.io (plain text, please)
- Let folks in the slack #falco channel know about a new release came out
## Falco Components Versioning
This section provides more details around the versioning of the components that make up Falco's core. It can also be a useful guide for the uninitiated to be more informed about Falco's source. Because `libs` makes up the greater portion of the source code of the Falco binary and is the home of each of the kernel drivers and engines, the [libs release doc](https://github.com/falcosecurity/libs/blob/master/release.md) is an excellent additional resource. In addition, the [plugins release doc](https://github.com/falcosecurity/plugins/blob/master/release.md) provides similar details around Falco's plugins. `SHA256` checksums are provided throughout Falco's source code to empower the end user to perform integrity checks. All Falco releases also contain the sources as part of the packages.
### Falco repo (this repo)
- Falco version is a git tag (`x.y.z`), see [Procedures](#procedures) section. Note that the Falco version is a sem-ver-like schema, but not fully compatible with sem-ver.
- [FALCO_ENGINE_VERSION](https://github.com/falcosecurity/falco/blob/master/userspace/engine/falco_engine_version.h) is not sem-ver and must be bumped either when a backward incompatible change has been introduced to the rules files syntax and loading logic, and/or when `FALCO_ENGINE_CHECKSUM` has changed. The checksum is computed by considering the available rules fields (see currently supported [Falco fields](https://falco.org/docs/reference/rules/supported-fields/)), the event types (see currently supported [Falco events](https://falco.org/docs/reference/rules/supported-events/)), and the supported driver schema version. A checksum indicates that something was not available in previous engine versions. See the [rules release guidelines](https://github.com/falcosecurity/rules/blob/main/RELEASE.md#versioning-a-ruleset) to understand how this affects the versioning of Falco rules. Breaking changes introduced in the Falco engine are not necessarily tied to the drivers or libs versions. The version number must be incremented every time and only when a single change or an atomic group of changes - which meet the criteria described above - is included in the `master` branch. Thus, a version bump can occur multiple times during the development and testing phases of a given release cycle. A given version bump must not group multiple changes that occurred sporadically during the release cycle.
- During development and release preparation, libs and driver reference commits are often bumped in Falco's cmake setup ([falcosecurity-libs cmake](https://github.com/falcosecurity/falco/blob/master/cmake/modules/falcosecurity-libs.cmake#L30) and [driver cmake](https://github.com/falcosecurity/falco/blob/master/cmake/modules/driver.cmake#L29)) in order to merge new Falco features. In practice, they are mostly bumped at the same time referencing the same `libs` commit. However, for the official Falco build `FALCOSECURITY_LIBS_VERSION` flag that references the stable libs version is used (read below).
- At release time Plugin, Libs and Driver versions are compatible with Falco.
```
Falco version: x.y.z (sem-ver like)
Libs version: x.y.z (sem-ver like)
Plugin API: x.y.z (sem-ver like)
Engine: x
Driver:
API version: x.y.z (sem-ver)
Schema version: x.y.z (sem-ver)
Default driver: x.y.z+driver (sem-ver like, indirectly encodes compatibility range in addition to default version Falco is shipped with)
```
### Libs repo
- Libs version is a git tag (`x.y.z`) and when building Falco the libs version is set via the `FALCOSECURITY_LIBS_VERSION` flag (see above).
- The driver version is not directly linked to the userspace components of the Falco binary. This is because of the clear separation between userspace and kernel space, which adds an additional layer of complexity. To address this, the concept of a `Default driver` has been introduced, allowing for implicit declaration of compatible driver versions. For example, if the default driver version is `5.0.1+driver`, Falco works with all driver versions >= 5.0.1 and <6.0.0.Thisisaconsequenceofhowthedriverversionisconstructedstartingfromthe`Driver API version`and`Driver Schema version`.DriverAPIandSchemaversionsareexplainedintherespective [libs driver doc](https://github.com/falcosecurity/libs/blob/master/driver/README.VERSION.md) -> Falco's `driver-loader` will always fetch the default driver, therefore a Falco release is always "shipped" with the driver version corresponding to the default driver.
- See [libs release doc](https://github.com/falcosecurity/libs/blob/master/release.md) for more information.
### Plugins repo
- Plugins version is a git tag (`x.y.z`)
- See [plugins release doc](https://github.com/falcosecurity/plugins/blob/master/release.md) for more information.
### Rules repo
- Rulesets are versioned individually through git tags
- See [rules release doc](https://github.com/falcosecurity/rules/blob/main/RELEASE.md) for more information.
- See [plugins release doc](https://github.com/falcosecurity/plugins/blob/master/release.md) for more information about plugins rulesets.
This document describes The Falco Project's branding guidelines, language, and message.
Content in this document can be used to publically share about Falco.
Falco is an open source security project whose brand and identity are governed by the [Cloud Native Computing Foundation](https://www.linuxfoundation.org/legal/trademark-usage).
This document describes the official branding guidelines of The Falco Project. Please see the [Falco Branding](https://falco.org/community/falco-brand/) page on our website for further details.
### Logo
There are 3 logos available for use in this directory. Use the primary logo unless required otherwise due to background issues, or printing.
There are 3 logos available for use in this directory. Use the primary logo unless required otherwise due to background issues or printing.
The Falco logo is Apache 2 licensed and free to use in media and publication for the CNCF Falco project.
@ -34,55 +32,6 @@ The primary colors are those in the first two rows.
> Cloud Native Runtime Security
### What is Falco?
Falco is a runtime security project originally created by Sysdig, Inc.
Falco was contributed to the CNCF in October 2018.
The CNCF now owns The Falco Project.
### What is Runtime Security?
Runtime security refers to an approach to preventing unwanted activity on a computer system.
With runtime security, an operator deploys **both** prevention tooling (access control, policy enforcement, etc) along side detection tooling (systems observability, anomaly detection, etc).
Runtime security is the practice of using detection tooling to detect unwanted behavior, such that it can then be prevented using prevention techniques.
Runtime security is a holistic approach to defense, and useful in scenarios where prevention tooling either was unaware of an exploit or attack vector, or when defective applications are ran in even the most secure environment.
### What does Falco do?
Falco consumes signals from the Linux kernel, and container management tools such as Docker and Kubernetes.
Falco parses the signals and asserts them against security rules.
If a rule has been violated, Falco triggers an alert.
### How does Falco work?
Falco traces kernel events and reports information about the system calls being executed at runtime.
Falco leverages the extended berkley packet filter (eBPF) which is a kernel feature implemented for dynamic crash-resilient and secure code execution in the kernel.
Falco enriches these kernel events with information about containers running on the system.
Falco also can consume signals from other input streams such as the containerd socket, the Kubernetes API server and the Kubernetes audit log.
At runtime, Falco will reason about these events and assert them against configured security rules.
Based on the severity of a violation an alert is triggered.
These alerts are configurable and extensible, for instance sending a notification or [plumbing through to other projects like Prometheus](https://github.com/falcosecurity/falco-exporter).
### Benefits of using Falco
- **Strengthen Security** Create security rules driven by a context-rich and flexible engine to define unexpected application behavior.
- **Reduce Risk** Immediately respond to policy violation alerts by plugging Falco into your current security response workflows and processes.
- **Leverage up-to-date Rules** Alert using community-sourced detections of malicious activity and CVE exploits.
### Falco and securing Kubernetes
Securing Kubernetes requires putting controls in place to detect unexpected behavior that could be malicious or harmful to a cluster or application(s).
Examples of malicious behavior include:
- Exploits of unpatched and new vulnerabilities in applications or Kubernetes itself.
- Insecure configurations in applications or Kubernetes itself.
- Leaked or weak credentials or secret material.
- Insider threats from adjacent applications running at the same layer.
Falco is capable of [consuming the Kubernetes audit logs](https://kubernetes.io/docs/tasks/debug-application-cluster/falco/#use-falco-to-collect-audit-events).
By adding Kubernetes application context, and Kubernetes audit logs teams can understand who did what.
### Writing about Falco
##### Yes
@ -98,60 +47,37 @@ Notice the capitalization of the following terms.
- the falco project
- the Falco project
### Encouraged Phrasing
Below are phrases that the project has reviewed, and found to be effective ways of messaging Falco's value add.
Even when processes are in place for vulnerability scanning and implementing pod security and network policies, not every risk will be addressed. You still need mechanisms to confirm these security barriers are effective, help configure them, and provide with a last line of defense when they fail.
##### Falco as a factory
This term refers to the concept that Falco is a stateless processing engine. A large amount of data comes into the engine, but meticulously crafted security alerts come out.
##### The engine that powers...
Falco ultimately is a security engine. It reasons about signals coming from a system at runtime, and can alert if an anomaly is detected.
##### Anomaly detection
This refers to an event that occurs with something unsual, concerning, or odd occurs.
We can associate anomalies with unwanted behavior, and alert in their presence.
##### Detection tooling
Falco does not prevent unwanted behavior.
Falco however alerts when unusual behavior occurs.
This is commonly referred to as **detection** or **forensics**.
---
# Glossary
# Glossary
#### Probe
This section contains key terms specifically used within the context of The Falco Project. For a more comprehensive list of Falco-related terminology, we invite you to visit the [Glossary](https://falco.org/docs/reference/glossary/) page on our official website.
#### eBPF Probe
Used to describe the `.o` object that would be dynamically loaded into the kernel as a secure and stable (e)BPF probe.
This is one option used to pass kernel events up to userspace for Falco to consume.
Sometimes this word is incorrectly used to refer to a `module`.
#### Module
#### Modern eBPF Probe
More robust [eBPF probe](#ebpf-probe), which brings the CO-RE paradigm, better performances, and maintainability.
Unlike the legacy probe, the modern eBPF probe is not shipped as a separate artifact but bundled into the Falco binary itself.
This is one option used to pass kernel events up to userspace for Falco to consume.
#### Kernel Module
Used to describe the `.ko` object that would be loaded into the kernel as a potentially risky kernel module.
This is one option used to pass kernel events up to userspace for Falco to consume.
Sometimes this word is incorrectly used to refer to a `probe`.
#### Driver
The global term for the software that sends events from the kernel. Such as the eBPF `probe` or the `kernel module`.
The global term for the software that sends events from the kernel. Such as the [eBPF probe](#ebpf-probe), the [Modern eBPF probe](#modern-ebpf-probe), or the [Kernel Module](#kernel-module).
#### Plugin
Used to describe a dynamic shared library (`.so` files in Unix, `.dll` files in Windows) that conforms to a documented API and allows to extend Falco's capabilities.
#### Falco
The name of the project, and also the name of [the main engine](https://github.com/falcosecurity/falco) that the rest of the project is built on.
#### Sysdig, Inc
The name of the company that originally created The Falco Project, and later donated to the CNCF.
#### sysdig
A [CLI tool](https://github.com/draios/sysdig) used to evaluate kernel system events at runtime.
The name of the project and also the name of [the main engine](https://github.com/falcosecurity/falco) that the rest of the project is built on.
- snprintf(error, SCAP_LASTERR_SIZE, "Too many sysdig instances attached to device %s. Current value for /sys/module/" PROBE_DEVICE_NAME "_probe/parameters/max_consumers is '%"PRIu32"'.", filename, curr_max_consumers);
+ snprintf(error, SCAP_LASTERR_SIZE, "Too many Falco instances attached to device %s. Current value for /sys/module/" PROBE_DEVICE_NAME "/parameters/max_consumers is '%"PRIu32"'.", filename, curr_max_consumers);
@ -4,13 +4,9 @@ This directory contains various ways to package Falco as a container and related
## Currently Supported Images
| Name | Directory | Description |
|---|---|---|
| [falcosecurity/falco:latest](https://hub.docker.com/repository/docker/falcosecurity/falco), [falcosecurity/falco:_tag_](https://hub.docker.com/repository/docker/falcosecurity/falco), [falcosecurity/falco:master](https://hub.docker.com/repository/docker/falcosecurity/falco) | docker/falco | Falco (DEB built from git tag or from the master) with all the building toolchain. |
| [falcosecurity/falco-driver-loader:latest](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader), [falcosecurity/falco-driver-loader:_tag_](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader), [falcosecurity/falco-driver-loader:master](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader) | docker/driver-loader | `falco-driver-loader` as entrypoint with the building toolchain. |
| [falcosecurity/falco-no-driver:latest](https://hub.docker.com/repository/docker/falcosecurity/falco-no-driver), [falcosecurity/falco-no-driver:_tag_](https://hub.docker.com/repository/docker/falcosecurity/falco-no-driver),[falcosecurity/falco-no-driver:master](https://hub.docker.com/repository/docker/falcosecurity/falco-no-driver) | docker/no-driver | Falco (TGZ built from git tag or from the master) without the building toolchain. |
| [falcosecurity/falco-builder:latest](https://hub.docker.com/repository/docker/falcosecurity/falco-builder) | docker/builder | The complete build tool chain for compiling Falco from source. See [the documentation](https://falco.org/docs/getting-started/source/) for more details on building from source. Used to build Falco (CI). |
| [falcosecurity/falco-tester:latest](https://hub.docker.com/repository/docker/falcosecurity/falco-tester) | docker/tester | Container image for running the Falco test suite. Used to run Falco integration tests (CI). |
| _to not be published_ | docker/local | Built on-the-fly and used by falco-tester. |
> Note: `falco-builder`, `falco-tester` (and the `docker/local` image that it's built on the fly) are not integrated into the release process because they are development and CI tools that need to be manually pushed only when updated.
| [falcosecurity/falco:latest](https://hub.docker.com/repository/docker/falcosecurity/falco), [falcosecurity/falco:_tag_](https://hub.docker.com/repository/docker/falcosecurity/falco), [falcosecurity/falco:master](https://hub.docker.com/repository/docker/falcosecurity/falco) | docker/falco | Distroless image based on the latest released tar.gz of Falco. No tools are included in the image. |
| [falcosecurity/falco:latest-debian](https://hub.docker.com/repository/docker/falcosecurity/falco), [falcosecurity/falco:_tag_-debian](https://hub.docker.com/repository/docker/falcosecurity/falco), [falcosecurity/falco:master-debian](https://hub.docker.com/repository/docker/falcosecurity/falco) | docker/falco-debian | Debian-based image. Include some tools (i.e. jq, curl). No driver-building toolchain support. |
| [falcosecurity/falco-driver-loader:latest](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader), [falcosecurity/falco-driver-loader:_tag_](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader), [falcosecurity/falco-driver-loader:master](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader) | docker/driver-loader | Based on falcosecurity/falco:x.y.z-debian (see above) plus the driver building toolchain support and falcoctl. This is intended to be used as an installer or an init container when modern eBPF cannot be used. |
| [falcosecurity/falco-driver-loader:latest-buster](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader), [falcosecurity/falco-driver-loader:_tag_-buster](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader), [falcosecurity/falco-driver-loader:master-debian](https://hub.docker.com/repository/docker/falcosecurity/falco-driver-loader) | docker/driver-loader-buster | Similar to falcosecurity/falco-driver-loader (see above) but based on a legacy Debian image (i.e. buster ). Recommended only for old kernel versions. |
Federico Di Pierro
poiana
dependabot[bot]
Leonardo Grasso
Mariell Hoversholm
Leonardo Di Giovanna
Melissa Kilby
Denis Romanenko
FedeDP
Luca Guerra
Tero Kauppinen
Kunal Singh
benierc
Nguyen Marc
Daniel Bodky
Aldo Lacuku
zayaanshahm
Shane Lawrence
John Thiltges
Federico Aponte
cpanato
Thomas Labarussias
Mark Stemm
Poiana
Andrea Terzolo
Francesco Furlan
harshitasao
Bill Vandenberk
Bill Vandenberk
Fede Barcelona
Jason Dellaluce
Samuel Gaist
Gianmatteo Palmieri
Paul Rey
Tom Müller
RohithRaju
Roberto Scolaro
Nitro Cao
Vicente J. Jiménez Miras
Richard Tweed
Lorenzo Susini
Massimiliano Giovagnoli
Gerald Combs
Adrian Mouat
Daniel Wright
hjenkins
jabdr
Anna Simon
Johanan Liebermann
Lorenzo Susini
Nicolas-Peiffer
Aurimas Rudinskis
Andrea Terzolo
Stanley Chan
Aizhamal Nurmamat kyzy
Aizhamal Nurmamat kyzy
rabbitstack
m.nabokikh
Furkan
Oscar Utbult
Alberto Pellitteri
cappellinsamuele
Andrea Bonanno
Nicolas-Peiffer
gentooise
vin01
Alessandro Brucato
Edvin Norling
Yarden Shoham
spyder-kyle
Hi120ki
Stefano
VadimZy
Mauro Ezequiel Moltrasio
Ian Robertson
Eric Engberg
Alessandro Brucato
Ravi Ranjan
Luca Guerra
Kaizhe Huang
Jeremi Piotrowski
joon
stephanmiehe
odidev
Matan Monitz
beryxz
Brad Clark
Milkshak3s
Sebastien Le Digabel
Mateusz Gozdek
Kevin Krakauer
Clemence Saussez
Angelo Puglisi
schie
Frederico Araujo
Frederico Araujo
TPT
Matt Moyer
Claudio Vellage
Josh Soref
Andrew Suderman
pablopez
rileydakota
m4wh6k
Mac Chaffee
Mike Stewart
Teryl
Andrea Terzolo
Shay Berkovich
Leonardo Di Donato
yoshi314
Marcin Kowalski
Zach Stone
Akos Kaldy
Angelo Puglisi
Calvin Bui
Erick Cheng
sai-arigeli
Dominic Evans
Manuel Gauto
Hitesh Sharma
David Windsor
David Windsor
Sverre Boschman
Michele Zuccala
Domenico Chirabino
spartan
Tom Keyte
Michal Schott
Loris Degioanni
maxgio
Thomas Spear
Lorenzo Fontana
Kaizhe Huang
Sverre Boschman
Yu Kitazume
diamonwiggins
ismail yenigul
natchaphon-r
Dan POP
Lorenzo Fontana