relationship between parameters

[skandbug]

The tool works great, but there is one problem that I don't quite understand.
tracee -f....
Are all subsequent filters and parameters related to and or progressive (the scope is constantly shrinking)?

[rafaeldtinoco]

@skandbug If I understood your question correctly, you're asking all filters are AND'ed (reducing the scope of what would be filtered), correct ?

That is why we have recently created the "multiple scopes" feature. We are in the middle of a big change in the project (turning all filtering capabilities into "policies").

LONG STORY SHORT:

1. in the beginning we had simple filters (event context and arguments)
2. started supporting filtering context "per event":

• global context filters (comm=/bin/bash, uid=1000)
• event filters (event=openat)
• event argument filters (event=openat openat.args.filename=/etc/passwd)
• event context filters (event=openat event.context.pid=1)

and then we faced what you're asking about. All the filters are ANDed up to this point, right ? Then we created the "multiple scopes" feature which allowed you to do something like:

tracee-ebpf --trace 1:event=openat --trace 1:openat.args.pathname=/etc/passwd --trace 2:event=security_file_open --trace 2:security_file_open.args.pathname=/etc/shadow

and all filters applied to scope 1 were ANDed and all filters applied to scope 2 were ORed.

But Providing up to 64 scopes in the cmdline isn't a great experience. Then we consider the cmdline is a SINGLE SCOPE (scope 1 lets say). Other scopes can only be provided by the feature we are creating called POLICIES.

3. With policies, each policy file (yaml file) has its own scope, events and filters (and filters are OR'ed among each policy). So currently, to have OR'ed filters you could create 2 or 3 policy files with the following contents:

zero.yaml

name: zero
description: zero
scope: 
  - global
defaultAction: log
rules:
  - event: openat
    filter:
      - args.pathname=/etc/passwd

one.yaml

name: one
description: one
scope: 
  - uid=0
  - comm=bash
  - follow
defaultAction: log
rules:
  - event: security_file_open
    filter:
      - args.pathname=/etc/passwd

ANd execute tracee with:

./dist/tracee --policy ./directory/

And both files would be loaded as policies.

If you read the YAML file you have basically 2 sets of filters:

1. scope (is the big filter for all the rest, and can be global, container, uid, pid, mntns, pidns, uts, comm, tree, binary, follow, ...). It will dictate the scope of events for that policy.

2. rules: declare multiple events in that session and, to each event, you can declare a filter. to each event you can have:

• context filter (pid, tid, uid, hosttid, container name, ...)
• event argument filter (openat.pathname)
• return filter (return code from the event)

For now there is a single action: to log. In the future there will be actions such as block, kill, call script, etc...

So if you want filters that do not reduce the intersection among them, you should create a difference policy for each workload you're interested in.

I hope this clarifies a bit (since this is all under development). More documentation at:

https://aquasecurity.github.io/tracee/v0.14/docs/policies/

[skandbug]

Your understanding is very correct, and the question is indeed "whether the purpose of reducing the scope step by step can be achieved by filtering parameters”.

There is another question to ask: In addition to the filter conditions listed in tracee, will other (not listed) events generated by the program also be recorded by tracee?

[skandbug]

I have a need like this:
By tracking the process ID (e.g., 1000), all events provided by Tracee such as all system calls, network and files of this process are obtained at the same time.
So the following command is constructed:

~/tracee -f pid=1000 -f set=syscalls -f set=network_events -f follow

Don't know if it is correct. Or how should I build it.

[rafaeldtinoco]

Okay, if I understand it correctly again (sorry your question wasn't so clear to me so I'm guessing things a bit). you want to pick lots of events from a SINGLE running process.

This can be obtained in multiple ways, like I said earlier. If you use a SINGLE scope, then you can do all through the cmdline and use the filter "PID=1000" as the "base" context filter (scope).

So lets say you do:

$ sudo ./dist/tracee --filter pid=$(pidof systemd)

You're now observing a "default set of events" coming ONLY from the running "systemd" process. The default events (from the "default set") are the following:

$ ./dist/tracee list | grep "\[default" | awk '{print $1}' | xargs
fchmod fchmodat fchownat fchown init_module ptrace setregid setgid setreuid setuid setresuid setresgid setfsuid setfsgid setpgid setsid setns process_vm_readv process_vm_writev finit_module memfd_create move_mount sched_process_exec security_inode_unlink security_socket_connect security_socket_accept security_socket_bind security_sb_mount container_create container_remove net_packet_icmp net_packet_icmpv6 net_packet_dns_request net_packet_dns_response net_packet_http_request net_packet_http_response

But If you want to hand pick specific events you can either use:

$ sudo ./dist/tracee --filter pid=$(pidof systemd) --filter event=XXX --filter event=YYY --filter event=ZZZ

Or you can select one of multiple event sets, like you said. Note that there are events that aren't on any set, so you would have to specifically select them with '--filter event=XXX' and not a set.

Note that this might have some performance impact as well (For both: the OS and tracee), specially for those events that happen very often.

[skandbug]

My goal is this.
Through PID, I want to know all the events that occur during the working process of this process, including system calls, network conditions, and file conditions.

How should I construct the statement based on tracee.