tracing-policies: support tags to categorize events

[tixxdz]

To categorize events we need a "tags" field that is a list of tags.

The Sigma Tags Specification is a good starting point:
https://github.com/SigmaHQ/sigma-specification/blob/main/Tags_specification.md

We first define namespaces for events, and we start with the
"observability" namespace.

observability: is the ability to collect and export data about the internal system state.

• "observability.filesystem": this event is about filesystem operations.
• "observability.privilege_escalation": this event is about the rights and permissions
  granted to a process or a user.
• "observability.process": this event is about an instance of a Linux program
  that is being executed.

tracing-policies: support tags to categorize events

[netlify]

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	014c671
🔍 Latest deploy log	https://app.netlify.com/sites/tetragon/deploys/66055c628706120008523cba
😎 Deploy Preview	https://deploy-preview-2008--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tixxdz]

@jrfastab the namespace I added is "observability", doing "tracing" is an alternative, strictly speaking they are flexible.

But I prefer to have it "observability.tracing" for things bpf, kprobes, etc instead or even later "integrity.tracing" things that modify the kernel or memory... be more into users/tools that will consume Tetragon events and filter those events by tags, compared to doing the developer way of "tracing.filesystem" or "tracing.x" which will still stay a bit low level and hard to consume from a higher perspective.

[mtardy]

Thanks that's a good addition! I just have some remarks on the Go code that could be simplified I think to be easier to read.

I'm not fan of the naming observability.privilege though I don't think very talkative while privilege_escalation or whatever is from MITRE or other standards is more explicit.

[mtardy]

I found it a bit hard to read and I would simplify it like this:

Suggested change

	func escapeTag(tag string) (string, error) {
	l := len(tag)
	if l < TpMinTagLen {
	return "", ErrTagSyntaxShort
	} else if l > TpMaxTagLen {
	l = TpMaxTagLen
	}
	t := fmt.Sprintf("%q", tag[:l])
	newLen := len(t)
	if newLen <= l || t[0] != '"' || t[newLen-1] != '"' {
	return "", ErrTagSyntaxEscape
	}
	// Remove double quoted string so we pretty print it later in the events
	return t[1 : newLen-1], nil
	}
	func escapeTag(tag string) (string, error) {
	if len(tag) < TpMinTagLen {
	return "", ErrTagSyntaxShort
	} else if len(tag) > TpMaxTagLen {
	tag = tag[:TpMaxTagLen]
	}
	escapedTag := strconv.Quote(tag)
	return escapedTag[1:len(escapedTag)-1], nil
	}

len(s) is just accessing a field in the string struct, also I don't think strconv.Quote (called by fmt.Sprintf with the %q word) can ever fail? Did you have something specific in mind that could make this function not work? I think we can rely on it or we can report a bug to the stdlib.

[tixxdz]

I didn't bother check, just quickly ensuring that we escape and stay in boundary, will see, thanks

[tixxdz]

hey @mtardy thanks I checked it and you are right fmt.Sprintf %q just ends up calling appendQuotedWith() which is basically the core of all these handling with the right parameters and we are sure to always have double quotes. Much appreciated ;-) , changed.

[tixxdz]

Thanks that's a good addition! I just have some remarks on the Go code that could be simplified I think to be easier to read.

I'm not fan of the naming observability.privilege though I don't think very talkative while privilege_escalation or whatever is from MITRE or other standards is more explicit.

privilege_escalation seems what other tools are using, it is explicit, with the right filters we can surely use it, let's see what other think

[jrfastab]

I'm not sure about this "official" supported tags. Tags can be anything I don't understand why we "support" a specific set of tags. I would just leave this as example tags.

[tixxdz]

So as we agreed some official tags are only in the doc to help keep things consistent, but I removed all the rest from the code, updated comment.

[jrfastab]

overall I agree tag fields are useful way for user to get a field they can use for DB or whatever event monitoring system for filtering, categorizing, etc. But, I'm against embedding specific tags in Tetragon. Why do we care?

[jrfastab]

Could you also add an export filter for tags? I think that would be useful to enable/disable certain types of events posting to JSON logs.

[tixxdz]

overall I agree tag fields are useful way for user to get a field they can use for DB or whatever event monitoring system for filtering, categorizing, etc. But, I'm against embedding specific tags in Tetragon. Why do we care?

@jrfastab so we care:

1. As I'm pushing example policylibrary: consolidate privileges raising operations into privileges-raise.yaml single policy #1957 the privileges "raise" tracking, I want to tag all events with "observability.privilege" or "observability.privilege_escalation" if you prefer, but we surely do want to groupe those.
2. We do want to have some standards and avoid developers pushing their own tags spread here and there...
3. With default shipped policy, users can quickly get those events knowing the standard tags, they won't guess! (but we still don't ship default yet, for now only examples and policylibrary)
4. For tracing policies that do enforcement we certainly won't tag those with "observability", so I want to avoid shipping say enforcement policies that may surprise users or block their workload by accident! we can in Tetragon daemon say load only "observability" policies for now, and users can augment on that, just avoid the selinux story of killing users's workload ;-)

So yeh I'm anticipating a bit, ok I will remove the default namespaces for now, let's get this merged first, then I think we will shortly have to update the policylibrary with default tags... in other words tell our users look for those tags and you get the corresponding events. I let you sleep on it... :-)

Could you also add an export filter for tags? I think that would be useful to enable/disable certain types of events posting to JSON logs.

Ok will see how to add the export filter, fix and repush.

[jrfastab]

@tixxdz I'm all for groupings by tags and a default set of tags for different groups of observability and enforcement. I still don't follow why that needs to be embedded in the codebase. I'm happy with a dir in policylibrary for each taggroup though.

[tixxdz]

Thanks that's a good addition! I just have some remarks on the Go code that could be simplified I think to be easier to read.

I'm not fan of the naming observability.privilege though I don't think very talkative while privilege_escalation or whatever is from MITRE or other standards is more explicit.

Thanks @mtardy for the review, and I changed it to observability.privilege_escalation ;-)

[tixxdz]

@tixxdz I'm all for groupings by tags and a default set of tags for different groups of observability and enforcement. I still don't follow why that needs to be embedded in the codebase. I'm happy with a dir in policylibrary for each taggroup though.

So summary:

• Removed tags from the code, now they are only in documentation which I think having a default set of tags would help to keep things consistent.
• For export filter, I will open issue for it and we do it as a follow up.
• For enforcing Tags limit at kubebuilder it is done

[jrfastab]

Go ahead and merge after rebase to avoid future conflicts. Also I'll watch it today so when its green I can merge it as well if I see it.