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>
