[New Feature] Support regex within rules

[harrysx]

Regex support will be useful for matching multiple conditions, for example a single rule to match

/var/log-6456546/1
/var/log-3566456/1
/var/log-5686786/1

Or:
1.1.1.1
1.1.2.1
1.1.3.1

[fntlnz]

@harrysx I'm closing this one since no one expressed interest in making this happen. Feel free to continue the discussion or send a PR with this feature regardless, in that case reopen the issue please.

[tspearconquest]

This would be helpful to have. Could you consider to reopen it?

[jasondellaluce]

@tspearconquest do you have specific use cases in mind? I can reopen this issue for you if you want.

My gut feeling is that nobody ever approached the problem for various technical issues:

• C++ doesn't have solid standard regex support, but we overcame this issue last year by adopting the RE2 library
• Evaluating regular expressions definitely has a non-negligible performance cost that we may not be able to accept in Falco rules. I think this has been the biggest blocker in the past, and this also justify the existence of the more lightweight operators startswith, endswith, contains, glob, and so on. If we ever get to actual regular expressions, for sure we will not support backtracking. Do you have a use case in mind that's not achievable with what we have right now?

[tspearconquest]

Hi Jason, RE2 would be perfectly fine for most use cases I can think of; and understood on all of it because the performance hit would probably increase syscall drops. I can work around not having regex, it just would be easier to be more specific with rules. For example, I want to have rules that are more specific than what glob matching allows. I can't specify `([0-9]{1,2}.){2}([0-9{1,2})` in glob, to match version numbers, using ? to match doesn't let me get specific enough, and I try to avoid * usage because it's too greedy.

[jasondellaluce]

Let's keep this open just so that's visible to other community members as well. However, I don't want to set any expectation about bringing this feature to mainline before having measured the performance tradeoffs.

/reopen

[poiana]

@jasondellaluce: Reopened this issue.

In response to this:

Let's keep this open just so that's visible to other community members as well. However, I don't want to set any expectation about bringing this feature to mainline before having measured the performance tradeoffs.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[tspearconquest]

/remove-lifecycle stale

[gccli]

regex match pods name of daemonset or statefulset maybe very useful

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[tspearconquest]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[jasondellaluce]

/remove-lifecycle stale

[leogr]

/assign @jasondellaluce

[jasondellaluce]

Closing this as the feature has been addressed in falcosecurity/libs#1904. Please anyone feel free to reopen this issue in case we haven't reached a satisfactory state.