-
Notifications
You must be signed in to change notification settings - Fork 910
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
IN operators may not work with fd.snet + netmasks #339
Comments
From rule maintenance perspective supporting IN for netmasks is way more manageable because rules will be written in terms of lists that can be appended by local rules. For Host IDS solutions it makes possible to define global whitelists for hosts to ignore and append environment specific netmasks for each deployment in local rules. |
mstemm
added a commit
to draios/sysdig
that referenced
this issue
Apr 2, 2018
Previously, if an expression had an xxx in (a, b, c, ...) check, the values a, b, c would be put in a set and xxx would do a set membership test to see if it's in the set. For almost all filtercheck types, this is preferred, but for some types like PT_IPV4NET, you can't actually do set membership tests, as the notion of equals isn't a simple == operator. So for PT_IPV4NET and any type that trivially returns false from ::flt_compare(), instead of doing the set membership test, compare the filtercheck values individually and return true as soon as you find one that is equal. This fixes falcosecurity/falco#339.
mstemm
added a commit
that referenced
this issue
Apr 2, 2018
Tests fix for #339. Depends on draios/sysdig#1091.
mstemm
added a commit
to draios/sysdig
that referenced
this issue
Apr 4, 2018
* Only do set equality/group searches for some types Previously, if an expression had an xxx in (a, b, c, ...) check, the values a, b, c would be put in a set and xxx would do a set membership test to see if it's in the set. For almost all filtercheck types, this is preferred, but for some types like PT_IPV4NET, you can't actually do set membership tests, as the notion of equals isn't a simple == operator. So for PT_IPV4NET and any type that trivially returns false from ::flt_compare(), instead of doing the set membership test, compare the filtercheck values individually and return true as soon as you find one that is equal. This fixes falcosecurity/falco#339. * Allow in matches for fd.net If a filter check has an in operator against a set of values, which gets turned into a piecewise equality comparison, treat the operator CO_IN just like CO_EQ.
mstemm
added a commit
that referenced
this issue
Apr 4, 2018
Tests fix for #339. Depends on draios/sysdig#1091.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In falco,
... in (a, b, c, ...)
expressions are implemented as a set membership test. However, when the expression is something likefd.snet
, where you want to compare against a netmask, it's actually better to break up the IN into a series of OR + equals.The text was updated successfully, but these errors were encountered: