Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Rules versioning #492

Merged
merged 6 commits into from Jan 29, 2019

Conversation

Projects
None yet
2 participants
@mstemm
Copy link
Contributor

commented Jan 3, 2019

Changes to explicitly track the version of both the falco engine and a rules file loaded by the engine. See https://github.com/falcosecurity/falco/wiki/Falco-Rules#versioning for more details.

This depends on
draios/sysdig#1288.

@mstemm mstemm requested a review from lorenzo-david Jan 3, 2019

@lorenzo-david
Copy link
Contributor

left a comment

LGTM

@lorenzo-david
Copy link
Contributor

left a comment

LGTM



if [ $NEW_CHECKSUM != $CUR_CHECKSUM ]; then
echo "Set of fields supported by falco/sysdig libraries has changed (new checksum $NEW_CHECKSUM != old checksum $CUR_CHECKSUM)."

This comment has been minimized.

Copy link
@lorenzo-david

lorenzo-david Jan 3, 2019

Contributor

Nice one! I like this approach.

This comment has been minimized.

Copy link
@mstemm

mstemm Jan 3, 2019

Author Contributor

Thanks!

@lorenzo-david
Copy link
Contributor

left a comment

LGTM
Note: we implicitly assume that we will always be backward compatible.

@lorenzo-david
Copy link
Contributor

left a comment

LGTM

# limitations under the License.
#

- required_engine_version: 9999999

This comment has been minimized.

Copy link
@lorenzo-david

lorenzo-david Jan 3, 2019

Contributor

Not really necessary but just for curiosity... what happens if we write some huge num, negative number, etc.? (e.g. 999999999999999999, -9, etc.)

This comment has been minimized.

Copy link
@mstemm

mstemm Jan 3, 2019

Author Contributor

It would come down to how lua and c convert the number. The check occurs in lua and lua's number type is a double (floating point double), so I don't think there's a chance of underflow.

@mstemm mstemm force-pushed the rules-versioning branch from 3642ec0 to 6c990cf Jan 3, 2019

@mstemm mstemm force-pushed the rules-versioning branch 2 times, most recently from 07a7b6a to f78a139 Jan 25, 2019

mstemm added some commits Jan 2, 2019

Add ability to print field names only
Add ability to print field names only instead of all information about
fields (description, etc) using -N cmdline option.

This will be used to add some versioning support steps that check for a
changed set of fields.
Add an engine version that changes w/ filter flds
Add a method falco_engine::engine_version() that returns the current
engine version (e.g. set of supported fields, rules objects, operators,
etc.). It's defined in falco_engine_version.h, starts at 2 and should be
updated whenever a breaking change is made.

The most common reason for an engine change will be an update to the set
of filter fields. To make this easy to diagnose, add a build time check
that compares the sha256 output of "falco --list -N" against a value
that's embedded in falco_engine_version.h. A mismatch fails the build.
Check engine version when loading rules
A rules file can now have a field "required_engine_version N". If
present, the number is compared to the falco engine version. If the
falco engine version is less, an error is thrown.
Unit tests for engine versioning
Add a required version: 2 to one trace file to check the positive case
and add a new test that verifies that a too-new rules file won't be loaded.
Rename falco test docker image
Rename sysdig/falco to falcosecurity/falco in unit tests.
Don't pin falco_rules.yaml to an engine version
Currently, falco_rules.yaml is compatible with versions <= 0.13.1 other
than the required_engine_version object itself, so keep that line
commented out so users can use this rules file with older falco
versions.

We'll uncomment it with the first incompatible falco engine change.

@mstemm mstemm force-pushed the rules-versioning branch from 4982c82 to 95edabf Jan 29, 2019

@mstemm mstemm merged commit 513cf2e into dev Jan 29, 2019

2 checks passed

Travis CI - Branch Build Passed
Details
Travis CI - Pull Request Build Passed
Details

@mstemm mstemm deleted the rules-versioning branch Jan 29, 2019

daixiang0 added a commit to daixiang0/falco that referenced this pull request Feb 10, 2019

Rules versioning (falcosecurity#492)
* Add ability to print field names only

Add ability to print field names only instead of all information about
fields (description, etc) using -N cmdline option.

This will be used to add some versioning support steps that check for a
changed set of fields.

* Add an engine version that changes w/ filter flds

Add a method falco_engine::engine_version() that returns the current
engine version (e.g. set of supported fields, rules objects, operators,
etc.). It's defined in falco_engine_version.h, starts at 2 and should be
updated whenever a breaking change is made.

The most common reason for an engine change will be an update to the set
of filter fields. To make this easy to diagnose, add a build time check
that compares the sha256 output of "falco --list -N" against a value
that's embedded in falco_engine_version.h. A mismatch fails the build.

* Check engine version when loading rules

A rules file can now have a field "required_engine_version N". If
present, the number is compared to the falco engine version. If the
falco engine version is less, an error is thrown.

* Unit tests for engine versioning

Add a required version: 2 to one trace file to check the positive case
and add a new test that verifies that a too-new rules file won't be loaded.

* Rename falco test docker image

Rename sysdig/falco to falcosecurity/falco in unit tests.

* Don't pin falco_rules.yaml to an engine version

Currently, falco_rules.yaml is compatible with versions <= 0.13.1 other
than the required_engine_version object itself, so keep that line
commented out so users can use this rules file with older falco
versions.

We'll uncomment it with the first incompatible falco engine change.

daixiang0 added a commit to daixiang0/falco that referenced this pull request Feb 10, 2019

Rules versioning (falcosecurity#492)
* Add ability to print field names only

Add ability to print field names only instead of all information about
fields (description, etc) using -N cmdline option.

This will be used to add some versioning support steps that check for a
changed set of fields.

* Add an engine version that changes w/ filter flds

Add a method falco_engine::engine_version() that returns the current
engine version (e.g. set of supported fields, rules objects, operators,
etc.). It's defined in falco_engine_version.h, starts at 2 and should be
updated whenever a breaking change is made.

The most common reason for an engine change will be an update to the set
of filter fields. To make this easy to diagnose, add a build time check
that compares the sha256 output of "falco --list -N" against a value
that's embedded in falco_engine_version.h. A mismatch fails the build.

* Check engine version when loading rules

A rules file can now have a field "required_engine_version N". If
present, the number is compared to the falco engine version. If the
falco engine version is less, an error is thrown.

* Unit tests for engine versioning

Add a required version: 2 to one trace file to check the positive case
and add a new test that verifies that a too-new rules file won't be loaded.

* Rename falco test docker image

Rename sysdig/falco to falcosecurity/falco in unit tests.

* Don't pin falco_rules.yaml to an engine version

Currently, falco_rules.yaml is compatible with versions <= 0.13.1 other
than the required_engine_version object itself, so keep that line
commented out so users can use this rules file with older falco
versions.

We'll uncomment it with the first incompatible falco engine change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.