Repository navigation
[auditd_manager] Expose immutable option and rules as textarea - #3760
Conversation
marc-gr
added
enhancement
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
53f4ad6 to
3e5618d
Compare
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
🌐 Coverage report
|
|
|
||
| It is important to note that with this setting set, the `elastic-agent` should never | ||
| be stopped, as it won't be able to resume processing `auditd` events until the | ||
| system is restarted. |
There was a problem hiding this comment.
@marc-gr does this also apply to Elastic Agent upgrades? i.e. if an agent restarts during an upgrade, will the system need to be restarted also to resume auditd event collection?
There was a problem hiding this comment.
I am afraid so. The process PID is part of the locked config, so once restarted it will be unable to start reading events again until the system is restarted. Please @adriansr correct me here if I am mistaken.
There was a problem hiding this comment.
Thanks for confirming @marc-gr - we should definitely include it within our docs, as well as in the integration description.
@nimarezainia do you know if agent could check if this option is enabled on hosts running the auditd_manager integration, and inform a user that a restart will be required before they go ahead with the agent upgrade?
There was a problem hiding this comment.
@jamiehynds lmk if the addition is enough
There was a problem hiding this comment.
@marc-gr Could we adjust slightly: Please note that if the immutable setting is enabled and the Elastic Agent on your host is stopped or restarted, a full system restart will be required in order to resume processing of Auditd events. Elastic Agent upgrades will also impact the Auditd event processing, and a system restart will be required during Agent upgrades too.
There was a problem hiding this comment.
@marc-gr also, do integration upgrades have an impact too? I assume not as the agent remains running when a user upgrades a package, but just want to be sure.
There was a problem hiding this comment.
I do not know about that tbh. Not sure how elastic agent deals with the underlying auditbeat. If the pid does not change it should be alright, if it does, then a restart will be required. Maybe someone from the @elastic/elastic-agent-control-plane can answer this.
There was a problem hiding this comment.
It should be possible to set the PID so an auditbeat restart should work. So as long as auditbeat does not fail because it cannot change rules it should work.
I tested restarting auditd on Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux after adding -e 2 and I was able to change the PID. I saw messages like
audit: CONFIG_CHANGE op=set audit_pid=1713 old=0 auid=4294967295 ses=4294967295 subj==unconfined res=1
auditd[1713]: Init complete, auditd 3.0 listening for events
auditctl[1726]: The audit system is in immutable mode, no rule changes allowed
There was a problem hiding this comment.
I think we should do a basic manual test by installing an Agent on VM and testing the scenario.
There was a problem hiding this comment.
Did some tests and made the required changes to skip configuration setting on auditbeat if immutable is set and the config is locked (elastic/beats#32498). Now after any restart events will continue to come in. Restart of the system will be required to apply any config change. cc @jamiehynds
marc-gr
changed the title
immutable optionimmutable option and rules as textarea
adriansr
left a comment
adriansr
left a comment
There was a problem hiding this comment.
Just a minor copy suggestion
…stic#3760) * Expose option * Add comment about update process and immutable to docs * Change audit rules to be a textarea instead of a list. * Update immutable docs * Change immutable config title
5 participants
What does this PR do?
immutableoption.Checklist
changelog.ymlfile.Depends on #3790