-
Notifications
You must be signed in to change notification settings - Fork 19
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
Only the first syscall group is being executed when there is multiple syscall groups #40
Labels
bug
Something isn't working
Comments
andrewkroh
added a commit
to andrewkroh/go-seccomp-bpf
that referenced
this issue
Dec 6, 2024
Add failing test case that demonstrates the bug. The expected behavior is to allow clone, but the default action of kill process is used instead. The log output is: filter_test.go:185: Expected allow, but got kill_process for test case 2 with seccomp_data=seccomp.SeccompData{NR:56, Arch:0xc000003e, InstructionPointer:0x0, Args:[6]uint64{0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} Relates: elastic#40
From your suggested test modification, I can see the bad logic in the instructions.
|
Thank you for helping but I think there might be some small mistake in the comment, and I think it should be like
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For example, if the policy have multiple syscall groups like
The expected behaviour is to execute the default action only when all syscall group not matches, but the current behaviour is to execute the default action if the first syscall group not matches. In this case, for syscall
clone
in the second group, it suppose to be allowed, but the result is kill.This behaviour is able to reproduce by adding test case in
filter_test.go
L190 withI think the root cause may be the default action is assembled to every group: https://github.com/elastic/go-seccomp-bpf/blob/main/filter.go#L223
The text was updated successfully, but these errors were encountered: