-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Auditbeat] Determine event.action based on diff against state #22170
[Auditbeat] Determine event.action based on diff against state #22170
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
The initial attempt with
doesn't work because you lose actions for renames and deletes (they just appear as attribute_modified. So perhaps we should only use the diff'ed action for updates. |
f783ba4
to
ee60d0d
Compare
Relates: #17347 |
if err != nil { | ||
return sid, owner, errors.Wrapf(err, "failed to convert path:'%s' to UTF16", path) | ||
} | ||
if err = GetNamedSecurityInfo(pathW, FileObject, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem here was:
- Some applications will open files for writing in exclusive mode (non FILE_READ_SHARED).
- ReadOpen above wants read access, so it fails with permission denied.
As GetSecurityInfo doesn't need read access to the file, but only the metadata (READ_CONTROL), I tried opening the file with just that flag. This also fails because the underlying CreateFile will internally add more permissions to the request (SYNCHRONIZE|FILE_READ_ATTRIBUTES) which causes it to still fail for files open with exclusivity.
Finally I came across this SO thread: https://stackoverflow.com/questions/58393139/createfilew-for-read-control-fails-with-access-is-denied-despite-being-owner-o that points to using GetNamedSecurityInfo, which internally does an NtOpenFile call with the minimum required permissions.
jenkins, test this |
1 similar comment
jenkins, test this |
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
With the current changes I am seeing One thing I noticed is that I get a sequence of created->deleted->created for new files. Is that explained by some OS behavior? I saw it with both a text editor saving a file and a firefox download on Windows. |
@andrewkroh I've tested under Windows server 2016 and didn't get the created->deleted->created sequence. This is saving a file with notepad: Also got similar result with notepad++, but lost the screen capture. Download a file with iexplore: My understanding is that Windows server 2016 and Windows 10 should behave similarly? Maybe differences in the underlying filesystem? |
Your test results look good. I was testing on GCP. The machine is still running if you wanted to look at it. |
Seems like a different behavior under Windows server 2019: This sequence is indeed what we're getting from fsnotify:
Looking at it via Process Monitor shows that when saving a file for the first time ( When saved using the I believe the first create-delete sequence is the file-selection dialog verifying that the target file can be created before the dialog is closed. For the Firefox issue however, I couldn't reproduce the created->deleted->created, but I got something that I believe is wrong: It's missing a final event for the target file ( |
jenkins test this please |
Rather than using an event.action that is derived from the OS flags provided in the file notification event the FIM module will determine the event.action based on the diff between the stored state for the path and the new state.
Update the file-state tracking to support the case where we receive a DELETE event but we observe the file as already re-created (event.Info is not nil and hashes are likely populated). Before this change, we would report a deletion but at the same store the hashes and file info. Then, a following CREATION event would be ignored because the diff-ing loggic doesn't take the previous action into account (in this case prev.action==Deleted). The best is to ignore the deletion and report on the observed file changes (if any). Otherwise we have to deal with complex logic in the cases where the OS event includes multiple actions ( ...|DELETED|...).
b0effb9
to
b30f19a
Compare
I tested out the a build of this on Windows 2019 (same one in GCP). The results LGTM🥇 Thank you @adriansr! Saving a file with no changes: Downloading a file with FF: |
Will add a changelog entry |
…ic#22170) Rather than using an event.action that is derived from the OS flags provided in the file notification event the FIM module will determine the event.action based on the diff between the stored state for the path and the new state. ---- Update the file-state tracking to support the case where we receive a DELETE event but we observe the file as already re-created (event.Info is not nil and hashes are likely populated). Before this change, we would report a deletion but at the same store the hashes and file info. Then, a following CREATION event would be ignored because the diff-ing logic doesn't take the previous action into account (in this case prev.action==Deleted). The best is to ignore the deletion and report on the observed file changes (if any). Otherwise we have to deal with complex logic in the cases where the OS event includes multiple actions ( ...|DELETED|...). Co-authored-by: Adrian Serrano <adrisr83@gmail.com> (cherry picked from commit 4a44fac)
… (#23788) Rather than using an event.action that is derived from the OS flags provided in the file notification event the FIM module will determine the event.action based on the diff between the stored state for the path and the new state. ---- Update the file-state tracking to support the case where we receive a DELETE event but we observe the file as already re-created (event.Info is not nil and hashes are likely populated). Before this change, we would report a deletion but at the same store the hashes and file info. Then, a following CREATION event would be ignored because the diff-ing logic doesn't take the previous action into account (in this case prev.action==Deleted). The best is to ignore the deletion and report on the observed file changes (if any). Otherwise we have to deal with complex logic in the cases where the OS event includes multiple actions ( ...|DELETED|...). Co-authored-by: Adrian Serrano <adrisr83@gmail.com> (cherry picked from commit 4a44fac) Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
What does this PR do?
Rather than using an event.action that is derived from the OS flags provided in the
file notification event the FIM module will determine the event.action based on the
diff between the stored state for the path and the new state.
Why is it important?
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.