Go signatures aren't usable outside of Tracee tree

[itaysk]

If someone wants to build their own Go signatures, following our instructions to create a standalone Go project and compile it with -buildmode=plugin the resulting artifact (.so) will not load in tracee-rules.
The reason is that the loader/linker checks for dependency version compatibility by comparing versions, but the hosting module (in our case tracee-rules) has no version. This is an upstream issue in Go: golang/go#31354 .

The reason it worked for us so far is that the signatures are compiled within the same directory as the tracee, so the import is treated as local. A workaround to make Go treat the import as local is to replace the module path in go.mod.

The GH issue indicates that the are no plans to address this for at least another year so the proposed solution for us is to extract tracee-rules/types into a separate Go module that both tracee-rules and the signatures would import.

thanks @AsafEitani for investigating

[pomozoff]

Awesome!

[danielpacak]

Before we extract tracee-rules/types somewhere I wanted to confirm that this solution really works and apparently it worked in this little POC

https://github.com/danielpacak/vulnerability-scanner
https://github.com/danielpacak/vulnerability-scanner-types
https://github.com/danielpacak/vulnerability-plugin-tomcat

@itaysk when you said "extract tracee-rules/types into a separate Go module" did you mean creating a new https://github.com/aquasecurity/tracee-types/main/go.mod repository or Go module somewhere within the existing https://github.com/aquasecurity/tracee/main/types/go.mod repository?

[itaysk]

@itaysk when you said "extract tracee-rules/types into a separate Go module" did you mean creating a new https://github.com/aquasecurity/tracee-types/main/go.mod repository or Go module somewhere within the existing https://github.com/aquasecurity/tracee/main/types/go.mod repository?

both will work but I meant the latter

[yanivagman]

Shouldn't have been closed yet

[danielpacak]

I created this Git template repository to get started quickly with custom Go signatures and I'm still bumping into similar issue, this time it is the pkg/external package 🤯:

sudo ./dist/tracee-ebpf \
  --output=format:gob \
  --output=option:parse-arguments \
  | ./dist/tracee-rules \
  --rules-dir /home/vagrant/tracee-go-signatures/dist \
  --input-tracee=file:stdin \
  --input-tracee=format:gob
2022/01/26 09:01:12 error opening plugin /home/vagrant/tracee-go-signatures/dist/tracee-go-signatures.so: plugin.Open("/home/vagrant/tracee-go-signatures/dist/tracee-go-signatures"): plugin was built with a different version of package github.com/aquasecurity/tracee/pkg/external
Loaded 0 signature(s): []

[AsafEitani]

In the last refactor we merged external into the main module.
@danielpacak suggested that we merge external and types together to provide the needed module to develop signatures.
I agree that that's the best solution.
Before we do so, @itaysk WDYT?

[rafaeldtinoco]

@rafaeldtinoco check this.

[danielpacak]

We've checked it with @AsafEitani and it works based on this sample project https://github.com/danielpacak/tracee-go-signatures.

However, we found another issue where the same sample Go signatures don't work with Ubuntu deb packages. This has to be investigated further.

[danielpacak]

BTW, may I suggest moving https://github.com/danielpacak/tracee-go-signatures repo to https://github.com/aquasecurity/tracee-go-signatures as Git project template. We can use it also as a reference and keep always up to date.

[rafaeldtinoco]

I would like that, indeed. It should be the base template for anyone trying to expand signatures using go.

[rafaeldtinoco]

However, we found another issue where the same sample Go signatures don't work with Ubuntu deb packages. This has to be investigated further.

@mtcherni95 and I were going through the issues after release so they're aware of all issues that could impact them. I'm glad you said it only affects .deb packages, I'll go over it. Thanks!