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

Refactor policy #4400

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Conversation

yanivagman
Copy link
Collaborator

1. Explain what the PR does

commit 9e6ddcd
Author: Yaniv Agman [email protected]
Date: Thu Nov 28 17:32:23 2024 +0200

test(pkg/cmd/flags): add unit tests for policy parsing functions

Add unit tests for recently added policy parsing functions:
- parseScopeFilters
- createSinglePolicy
- parseEventFilters

commit ec0ec43
Author: Yaniv Agman [email protected]
Date: Thu Nov 28 14:16:57 2024 +0200

refactor: simplify CreatePolicies function structure

Split the large CreatePolicies function into smaller, focused functions
for better readability and maintainability. The main changes:

- Split policy creation logic into separate functions
- Simplified function signatures and parameter passing
- Made variable naming more consistent
- Improved error handling organization

No functional changes, only code reorganization.

commit d575f3d
Author: Yaniv Agman [email protected]
Date: Mon Nov 25 17:54:48 2024 +0200

refactor: align filters with policy rule structure

Restructure filters to match tracee's policy structure by moving event-specific
filters into policy.Rules. Main changes:

- Move DataFilter, ScopeFilter and RetFilter from top-level maps into
  policy.Rules[eventID]
- Remove filter.go and its flag as event filtering is now handled through
  the policy structure
- Adjust all filter operations to work with the new Rules-based structure

This change better reflects tracee's policy design where each event has
its own set of filters under a rule, preparing the stage for moving from
matched_policies to matched_rules resolution.

commit cc8947d
Author: Yaniv Agman [email protected]
Date: Thu Nov 28 11:48:17 2024 +0200

docs: split filter help into scope and events help

Split the filter help message into separate scope and events help messages
to match the CLI structure. Moved documentation from the deprecated filter
flag into their respective --scope and --events flag help messages.

2. Explain how to test it

3. Other comments

This commit renames the `parameters` field in event definitions to `fields`.
This change reflects the evolving nature of Tracee, which now supports various
event types beyond just syscalls.

The term "fields" more accurately describes the structured data within events,
aligning with the concept of event schemas and the `data` section in the new
event structure.

This renaming also avoids future confusion with the planned introduction of
"event parameters," which will be configurable settings for modifying event
behavior.
Split the filter help message into separate scope and events help messages
to match the CLI structure. Moved documentation from the deprecated filter
flag into their respective --scope and --events flag help messages.
Restructure filters to match tracee's policy structure by moving event-specific
filters into policy.Rules. Main changes:

- Move DataFilter, ScopeFilter and RetFilter from top-level maps into
  policy.Rules[eventID]
- Remove filter.go and its flag as event filtering is now handled through
  the policy structure
- Adjust all filter operations to work with the new Rules-based structure

This change better reflects tracee's policy design where each event has
its own set of filters under a rule, preparing the stage for moving from
matched_policies to matched_rules resolution.
Split the large CreatePolicies function into smaller, focused functions
for better readability and maintainability. The main changes:

- Split policy creation logic into separate functions
- Simplified function signatures and parameter passing
- Made variable naming more consistent
- Improved error handling organization

No functional changes, only code reorganization.
Add unit tests for recently added policy parsing functions:
- parseScopeFilters
- createSinglePolicy
- parseEventFilters
@@ -12,7 +11,7 @@ import (
)

type DataFilter struct {
filters map[events.ID]map[string]Filter[*StringFilter]
filters map[string]Filter[*StringFilter]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rscampos this conflicts with your effort.

enabled: false,
}
}

// GetEventFilters returns the data filters map for a specific event
// writing to the map may have unintentional consequences, avoid doing so
func (af *DataFilter) GetEventFilters(eventID events.ID) map[string]Filter[*StringFilter] {
return af.filters[eventID]
// TODO: encapsulate by replacing this function with "GetFieldFilter(fieldName string) StringFilter"
Copy link
Member

@geyslan geyslan Nov 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible, GetFieldFilter(field int) should receive an int.

--- EDIT

I'm concerned about calls from hotpaths, if it's not the case, ignore it.

Comment on lines +131 to +139
// Check filters under Rules
for _, rule := range p.Rules {
if rule.DataFilter.Enabled() ||
rule.RetFilter.Enabled() ||
rule.ScopeFilter.Enabled() {
hasUserlandFilters = true
break
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this logic set an internal flag to be checked via a Rules public method as a shortcut in the pipeline?

}

type RuleData struct {
EventName string
Copy link
Member

@geyslan geyslan Nov 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An int (eventID) rather?

ProcessTreeFilter *filters.ProcessTreeFilter
BinaryFilter *filters.BinaryFilter
Follow bool
Rules map[events.ID]RuleData
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm aware that you're just following the current structure definition but, just as a reminder, we'll better encapsulate it converting all public objects to private and make them accessible only by specific methods as we already started in policy.Manager.

@geyslan
Copy link
Member

geyslan commented Nov 29, 2024

I've skimmed it and put some thoughts. When the conflicts are resolved, gonna check it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants