We have a filter providing an HSM via reparse point but we are finding increasing use of EAs by some anti-malware products. We propose to remove the EA when we ‘stub’ a file (remove primary data, and add reparse point) but replace the EA if the file is accessed causing us to ‘unstub’ the file (restore primary data and remove reparse point). Has anyone else tried this or see major issues with this.
If you need to work with different AVs - you cannot imagine even 10% of
cases.
Whatever can go wrong, will go wrong at the worst time - no logging, but
data loss.
I am surprised AVs/AMs use EAs. Does it remove a reparse tag?
I can see quite a few reentry issues with AVs here, if you remove their
tags even momentarily.
Dejan.
Are they normal EAs or Kernel Purge EAs (c.f. https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/kernel-extended-attributes)?
@“Scott_Noone_(OSR)” We are seeing both. Kernel ones on Azure, but regular ones set by a security product (am I allowed to name vendors here?)
Kernel Purge EAs are generally used by A/V’s to avoid scanning files that haven’t changed (e.g. across reboots). IMO it doesn’t make sense to restore these given that the file may have changed “in the cloud” since the last local scan.
For normal EAs there’s no right answer…They’re a pretty fragile mechanism for storing anything important given that they’re lost when copying to file systems that don’t support them (e.g. FAT32). I’d be inclined to just leave them on the local stub file/reparse point and not bother saving/restoring them.
And, FWIW, having written two HSM filters we’ve never saved/deleted/restored EAs. This also appears to be the policy of the Cloud Filter, which doesn’t necessarily mean it’s “right” but just another example.