User interface for event parameters

[AsafEitani]

Currently we are using filters to provide parameters for the symbols_loaded and print_mem_dump events. This is an abuse of the filters and resulted in some workarounds. We should implement a new way which users can provide parameters for events that needs them. This can also affect the hooked_syscalls event as the syscall list is constant and can be varied with this feature.

As part of this change, we should also verify that the parameters given by the user are valid.

[itaysk]

might be related to signature configuration issue, when signatures become events https://github.com/aquasecurity/tracee/issues/1423

[geyslan]

As discussed offline, postponing it.

[yanivagman]

Shouldn't have been closed

[yanivagman]

We can think about event parameters as a way to configure the event. It may be that different policies will want to configure an event differently, e.g. choose different symbols for the symbols_loaded event, so we need to allow setting the event's configuration per policy. It may also be that other (non parameter) configurations will be added in the future. For example, we may add the ability to configure the severity (or priority) of an event. To allow that, we better add another level in the hierarchy so we get: event.config.params.xxx (to set parameter xxx of the event) event.config.severity (to override severity of the event)

[itaysk]

can you elaborate what does it mean that a user sets the value of severity (what's the use case)? If the user doesn't care about the reported event severity and wants to classify it otherwise, they can just ignore what the event has. if they really really need the event json to show the overridden severity I think they should do it outside of tracee

[yanivagman]

can you elaborate what does it mean that a user sets the value of severity (what's the use case)? If the user doesn't care about the reported event severity and wants to classify it otherwise, they can just ignore what the event has. if they really really need the event json to show the overridden severity I think they should do it outside of tracee

For different users, severity/priority of an event can be different. This is obvious for non-signature events where severity will always be 0, but also for signatures - some users may want to mark anti-debugging as a high risk while for others it may be legitimate in most cases, so they will want to lower its severity. Since we already provide this field and there's no much use of it in the above cases, we can let the user override it's default value and take advantage of it.

[itaysk]

thanks for clarifying, so I think my comment still holds (only about tending to the severity use case)

[yanivagman]

thanks for clarifying, so I think my comment still holds (only about tending to the severity use case)

Not sure what you mean by that. Anyway the issue here is not about adding the ability to config the severity field but adding event parameters. Do you have any comment about the suggested hierarchy? event.config.params.xxx

[itaysk]

It would be best to discuss this in the context of the feature's design, which isn't mentioned here. How do we expect users to configure this? how does it tie into the policy?

[yanivagman]

How do we expect users to configure this?

Like this: event.config.params.xxx=y where xxx is a parameter of the given event and y is the value to set the parameter to

how does it tie into the policy?

As another field in the rule (like filters we currently have)

[itaysk]

can you please give an example for how a user set configuration? it would be easiest to discuss this way

[yanivagman]

can you please give an example for how a user set configuration? it would be easiest to discuss this way

rules:
  - event: symbols_loaded
    config:
      - params.symbols=symbol1
    filter:
      - comm=ls

[geyslan]

e.g. choose different symbols for the symbols_loaded event, so we need to allow setting the event's configuration per policy.

@yanivagman so Policy must be changed like:

diff --git a/pkg/policy/policy.go b/pkg/policy/policy.go
index 2739dc18..c7d06730 100644
--- a/pkg/policy/policy.go
+++ b/pkg/policy/policy.go
@@ -22,7 +22,7 @@ const (
 type Policy struct {
        ID                int
        Name              string
-       EventsToTrace     map[events.ID]string
+       EventsToTrace     map[events.ID]EventConfig
        UIDFilter         *filters.BPFUIntFilter[uint32]
        PIDFilter         *filters.BPFUIntFilter[uint32]
        NewPidFilter      *filters.BoolFilter

[geyslan]

I'm starting to work on this. Could you provide examples of what should remain as args and what should be changed to params for the three examples given above?

• symbols_loaded
• print_mem_dump
• hooked_syscalls

Should parameters be set to event (enforcing all policies) or should each policy be considered as having its own event parameter?

[geyslan]

Postponing this since we have to better specify where parameters should lie and what should they affect (as mentioned in my previous comments).