Add configuration for seccomp #344
Conversation
|
Does having this flag in versions of Filebeat older than 8.12 (or whichever version it was introduced in) cause any error on startup? I have no issue adding it, but don't want to cause issues for anyone not ready for a beta feature. |
|
I am uncertain when it was added, but it is there on at least version 6.4, which is the oldest reference I can find to it in the docs. We are running 6.8. I think the beta note is just them not updating their documentation. There are already multiple sections, is there a clean way of adding another version check without it getting too messy? |
|
If it's been there that long then I think it's safe to add. We've never made a clear decision about how many versions to support, but this seems reasonable in any case. Do you think this is ready to merge, or are there more changes or checks we need to make? |
|
We have deployed it, and it seems fine. I would think that the other platforms could be tested, but we do not have any BSDs or Windows to test on. I think it ought to be fine there, but cannot be sure without testing. I think the "Puppet" part of it is good to merge, just maybe only release this commit behind a feature version as opposed to a point release. |
|
Hello, if we run filebeat 7.12 on debian 12 it will require rseq to be allowed else it fails, i think the rseq system calls should be allowed too https://kifarunix.com/how-to-fix-filebeat-glibc-related-errors/ to fix the problem. May i add a commit to this pull request ^^ ? |
Without this disabled, we get horrific SIGABRT every time the service starts, which is annoying to say the least.
I would deploy this as an empty hash, but I worry about what will happen if the key is set on platforms where seccomp makes little sense. Hope someone can provide some guidance and/or testing.
Details on the extended config:
https://www.elastic.co/guide/en/beats/filebeat/8.12/linux-seccomp.html