-
Notifications
You must be signed in to change notification settings - Fork 525
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
[meta] running java-attacher #7023
Comments
This is blocked at the moment by elastic/elastic-agent#95 and figuring out how custom seccomp filters should be configured and applied when managed by Elastic Agent. |
2022-01-25: Updated description to reflect also the alternative option. |
Now that Option C has been selected and the changes for it have been merged, what is left to satisfy this issue? |
I think the only thing left to do is test across all supported platforms:
(Pretty sure Stuart has tested on Linux already, but maybe not since the seccomp changes were made?) |
I've tested on linux/amd64, but not 386 |
@stuartnelson3 please close this issue once you finished testing on linux. |
Status
When running under linux, forking and running the java-attacher is not currently allowed, as APM Server uses seccomp to filter allowed syscalls.
Options
(A) Provide seccomp rules to allow the required syscallsThe
fork/exec
privileges added via seccomp-bpf need to be limited to the java-attacher process.The below matrix tracks the status of forking and running the java-attacher with the listed operating system/architecture + apm-server mode pair.
nb. Linux rows are split out by CPU architecture, because each will require an update to its own seccomp policy. seccomp is only supported in linux.
Related Issues:
(B) Investigate static analysis of fork/exec syscallsVerify APM Server's dynamic call graph #7109
(C) Disable seccomp
#7305
Update: We decided to move forward with option (A) for now. Focusing on seccomp is more aligned with currently ongoing effort in the agent team. With option (B) it would be hard to ensure that all code paths are checked for restricted syscalls. Given some related conversations around moving subprocesses to their own Integration or Sub-Integration this might not be needed in the future.Update the second: it turns out seccomp filters don't support our needs (i.e. allowing only some programs to be executed). After further consideration, we have decided it is safe to disable the current seccomp implementation in APM Server.
The text was updated successfully, but these errors were encountered: