Tracee Policies

[yanivagman]

Now that we have sets of filters in place, we can move to the next step of implementing runtime policies in tracee.
Following is a proposal for how we can implement policies in Tracee. Any comments/suggestions are welcome.

A runtime policy is composed of:

• Policy Name
• Description
• Scope (on which the policy will be applied)
• Rules list, where each rule have:
  • event trigger
  • specific filters for event context/arguments (optional)
  • actions - TBD (optional)

Policies will be defined in files - one policy per file
A policy can be given to tracee using a new "--policy" flag, which takes the path of the policy as an argument

Following is an example for such a policy, defined in a yaml file:

name : new_containers
description: “This policy will be applied on any new container created in the system”
scope:
      - container=new
      - binary!=/usr/bin/dockerd,/usr/bin/runc
defaultAction: log             # (/webhook/block/kill)
rules:
    - event:security_file_open
      filter:
          - uid=1000
          - arg.pathname=/tmp/a,/etc/passwd
          - arg.pathname!=/tmp/exception    # longest prefix wins!
          - arg.flags=O_CREAT
      action:
          - webhook
      # in the future, we may support more than one rule per event type
    - event: anti-debugging
      filter:
          - comm!=gdb,strace
          - binary=/whatever
      # if no action is given - default action is taken
    - event: net_packet_ipv4:
      filter:
          - traffic=ingress
          - protocol=tcp
          - dst.port=80
      action:
          - block
    - event: process_exec
      filter:
          - comm=bash
      action:
          - block
          - webhook:
              url: sdfdsf.com
          - log:
              format: pathname
              # TBD: format usage

[itaysk]

it would be helpful to consider how policy maps to current cli flags. let me know if I get it right or I missed something:

--trace <event.context.something>= --> entry in scope
--trace binary, tree, follow? => entry in scope
--trace event= --> entry in events
--trace <event.args.something>= --> entry in event under events

not sure how to place event=something* and set=.

[itaysk]

Actually this is also an entry in event under events

ok, so how do we define what is in scope and what is in event? (categorically, not by example)

[NDStrahilevitz]

ok, so how do we define what is in scope and what is in event? (categorically, not by example)

The difference is between, "I only want this filter on this event (context filter)" and "I want this filter applied globally (as a scope)".

[itaysk]

ok, so all filters are available in both scope and event? and the difference is their affect being global or just for the event?

[yanivagman]

This is true for context filters.
Event also has argument filters, so it cannot be applied in scope

[itaysk]

We talked and Yaniv put it clearly to me as: scope is for choosing the workload, and events is for choosing the events.

[itaysk]

I'm not sure about the way operators are declared. in your example:

- anti-debugging:
                comm:
                    not_equal:  
                      - gdb
                      - llvm-gdb

^^ here we use not_equal to operate.

     - security_file_open:
              argument.pathname:
                  - /tmp/*

^^ here I suppose it's implicitly "equal" but then the value contains a modifier *

    - net_packet_ipv4:
              protocol:
                  tcp

^^ here there's no operator at all

Additionally, the scope section ignores operators but there might be there as well?

I'm thinking maybe to just use the same operators we have today in the cli? It's more readable for the user and probably will be easier to implement since the code is already there.

So it will look like:

events:
     - security_file_open:
              filter: 
                  - argument.pathname=/tmp/*
     - anti-debugging:
              filter:
                  - comm!=gdb
                  - comm!=llvm-gdb
    - net_packet_ipv4:
             filter: 
                  - protocol=tcp
                  - port-80
              action:
                  - block  

alternatively, if we want structured operators then we need to 1) use them more consistently across the yaml 2) make sure all current and future ones are easily supported

[yanivagman]

I'm thinking maybe to just use the same operators we have today in the cli? It's more readable for the user and probably will be easier to implement since the code is already there.

Good idea. I updated the policy according to your suggestion.

[NDStrahilevitz]

When users enable container enrichment, I it would be a good idea to allow scoping by a container image/SHA as well, WDYT?

[itaysk]

yes definitely, but aren't all enrichment stuff end up in the context, and therefore are included in:
--trace <event.context.something>= --> entry in scope
?

[NDStrahilevitz]

Yes, but this isn't a scope, see above what I mean.

[yanivagman]

Yes, we should add this (and pod) information to the scopes.
However, this will require some extra work, and has some issues to that need to be addressed (or to be aware of):

1. We may want to translate container/pod info to container id so we can filter by it in kernel code. The benefit of doing this is saving the need to submit to userspace if the event shouldn't be traced, as well as being able to apply some actions in bpf code.
2. Since enrichment only happens after the first event is submitted, we need to think how to take care of the first events without context

[itaysk]

why don't we make all of those binary, container, pod part of the event context? it sounds more intuitive to me

[NDStrahilevitz]

Except the binary, they are all already part of the event context. Some of those should just also be available as part of the scope (separated from the event context so you can do --trace image=redis:latest for example (which is currently impossible).

[itaysk]

binary!=/usr/bin/dockerd,/usr/bin/runc

^^ shows multi value filter in same line

filter:
                  - context.comm!=gdb
                  - context.comm!=strace

^^ shows multi value filter as two lines

are both options going to be possible or we want to choose one?

BTW it is OR in both cases right?

[NDStrahilevitz]

If we reuse our current scope parsing code from the CLI both are valid.
We will probably have some parsing layer between the scope file to cli inputs so we can choose to add some additional syntax rules, and I think in that case not allowing duplicate keys will be better.

[yanivagman]

Yes, both cases are valid, and yes, it is OR in both

[rafaeldtinoco]

From our last talk we were going to start with network-related policies (so we could apply rules of allow/deny according to network values). Is that still the case? If that is so, I should implement a network-related filter for the net_packet events, and a way to allow/deny the flows.

[yanivagman]

From our last talk we were going to start with network-related policies (so we could apply rules of allow/deny according to network values). Is that still the case? If that is so, I should implement a network-related filter for the net_packet events, and a way to allow/deny the flows.

That's correct. The policy given in the above example is just using what we already have in Tracee PLUS the ability to block network according to ip/port/protocol, which will be the first action to implement.

[yanivagman]

I updated the policy and changed "events" list to be "rules" list, where a rule is composed of:

• event trigger
• filter (optional)
• actions (optional)

[itaysk]

actions are sometimes a dict (webhook) and sometimes string (block). depending on if configuration is needed.
webhook shows in both forms, I think it should always be a dict (so fix the example)

[itaysk]

sorry for another name debate but don't we call audit print everywhere else? should we call it print here as well

[yanivagman]

I think that "print" gives the wrong connotation so I suggested to use "audit" instead. Another option can be "notify". WDYT?

[itaysk]

notify competes with webhook IMO
I'm ok with audit if you think it's best

[yanivagman]

since webhook is now a printer, it makes sense to put it under notify

[itaysk]

for audit format - we need to rethink this as the format needs to fit with the "everything is an event" scheme. now everything tracee emits needs to follow the same common json structure, so we can't let the user print arbitrary strings.

[yanivagman]

This is why I left it as TBD