Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT] Sig on sigs #4314

Closed
wants to merge 3 commits into from
Closed

Conversation

AsafEitani
Copy link
Contributor

1. Explain what the PR does

"Replace me with make check-pr output"

2. Explain how to test it

3. Other comments

Copy link
Member

@geyslan geyslan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a simple anti_debugging signature, tracee-ebpf and analyze continues to work, but I can't say for the specific signature of signatures... I don't have a proper input file.

@@ -4,6 +4,8 @@ import (
"context"
"errors"
"fmt"
"github.com/aquasecurity/tracee/pkg/cmd/initialize"
Copy link
Member

@geyslan geyslan Sep 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is causing the embedding issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved by decoupling the sigs from the initialize package

@@ -142,7 +144,7 @@ func main() {
if err != nil {
return err
}

_ = initialize.CreateEventsFromSignatures(events.StartSignatureID, sigs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To solve undefine error on undefined: embed.BPFBundleInjected, copy CreateEventsFromSignatures() to this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved by decoupling the sigs from the initialize package

cmd/tracee-rules/output.go Outdated Show resolved Hide resolved
@AsafEitani AsafEitani marked this pull request as ready for review September 22, 2024 09:36
Copy link
Collaborator

@NDStrahilevitz NDStrahilevitz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, if I understand it right from the code, the issue was that just as events have event dependencies which we need to ensure are loaded even if the users does not select them, so goes the case now for signatures.

Now, since I know the internal usecase for this, If I got the code right then I'm not sure that it is actually the desired behavior. The desired usecase was for a signature aggregating data on the behavior of all other signatures with certain characteristics. But this does not imply that we would want to load each such signature. Rather, it implies that it would aggregate this info based on the selected signatures, which sounds about right.

Now, I might be wrong about what the code does. Whether this is the case or not, it lacks documentation on:

  1. What is the resolved gap in the code (the code is meant to handle signatures as dependent on others, it didn't work because of X)
  2. How the gap was resolved (Signatures which are dependencies are now selected for emission - previously they were only loaded)
  3. More concrete documentation in the code explaining the logic, the word "processing" for example was used as a generic descriptor for a concrete action - finding dependent signatures which are available in the plugin but not selected for emitting.

Finally, please fix the style so that the tests pass.

@@ -27,6 +29,8 @@ const (
signatureBufferFlag = "sig-buffer"
)

var inputs engine.EventSources
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose of moving this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feeding the signatures as events back to the input channel.

@@ -142,7 +144,7 @@ func main() {
if err != nil {
return err
}

_ = initialize_sigs.CreateEventsFromSignatures(events.StartSignatureID, sigs)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there no error check?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copied from the one binary mode.

return
}
default:
inputs.Tracee <- e.ToProtocol()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the inputs from the previous file is now a global variable for this? What's the reasoning?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feeding back the signatures.

@AsafEitani
Copy link
Contributor Author

AsafEitani commented Sep 23, 2024

@NDStrahilevitz So the purpose of the PR is to allow signatures to process other signatures.
The original issue was that the sigs on sigs works on the one binary, but not in analyze mode or tracee-rules, this PR fixes that.
This includes the event selection process as well as feeding the signatures as events back to the input channel, mainly the latter.
Most of the code here was either written by @geyslan or copied from other places in Tracee.
Also the lint issues are not in the code that was changed in this PR, and I tried fixing it with make but it still has problems, no idea why.

@geyslan
Copy link
Member

geyslan commented Sep 24, 2024

I'm debugging internal integration (bump) and faced this commit, it seems related to this current effort: https://github.com/aquasecurity/tracee/pull/3681/commits

@NDStrahilevitz NDStrahilevitz marked this pull request as draft September 25, 2024 12:33
@NDStrahilevitz NDStrahilevitz changed the title Sig on sigs [DRAFT] Sig on sigs Sep 25, 2024
@NDStrahilevitz
Copy link
Collaborator

Turned to draft in favor of #4327

@NDStrahilevitz
Copy link
Collaborator

Closing in favor of #4327.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants