enrich: Add SHA256 hash of executable to SYSCALL records

[rhaist]

Summary

Implements the exe-hash enrichment option requested in #222. When enabled, LAUREL reads the executable file referenced in SYSCALL.exe at event processing time and appends its SHA256 digest as an EXE_HASH field to the SYSCALL record.

Motivation

Process execution events carry the path of the executed binary, but not a hash. This makes it difficult to detect cases where a binary has been replaced or tampered with between invocations, or where a known-bad executable is renamed to evade file path–based detection rules. Adding a content hash allows analysts and SIEM rules to correlate against threat intelligence feeds and detect renamed or modified binaries.

Configuration

The feature is disabled by default to avoid I/O overhead for users who don't need it. Enable it by adding the following to etc/laurel/config.toml:

[enrich]
exe-hash = true

When enabled, each SYSCALL record gains an EXE_HASH field containing the lowercase hex-encoded SHA256 of the executable:

"SYSCALL": { ..., "exe": "/usr/bin/curl", "EXE_HASH": "b94d27b9934d3e08a52e52d7..." }

If the file cannot be read (e.g. the process has already exited and the binary was deleted), the field is silently omitted rather than causing an error.

Implementation notes

• Uses the sha2 crate (pure Rust, no new system library dependencies). On x86/x86_64, hardware acceleration is detected via CPUID; on aarch64, via getauxval (available since glibc 2.16 / CentOS 7). Neither path introduces new minimum glibc version requirements for the distributed binaries.
• Hashing is done synchronously in the audit processing loop. For deployments with very high execve rates or slow storage, consider the performance implications before enabling.

Testing

A unit test (exe_hash in src/coalesce.rs) writes a temporary file, constructs a synthetic SYSCALL+EXECVE+EOE event pointing at it, runs it through Coalesce with enrich_exe_hash = true, and asserts the correct SHA256 appears in the output.

Closes #222

[hillu]

Thanks for the PR. Placing the enrichment late into the chain makes sens, However, I'd rather not merge the feature as implemented since there is potential for seriously DoSing the process and some measures should be taken to keep system administrators from shooting themselves in the foot.
I can think of at least two obvious measures to avoid problems

• a configurable maximum file size for binaries to consider for hashing
• a cache for hashes based on ID + inode number that takes some other filesystem metadata into account. This cache should have a configurable limited number of entries and probably LRU/ageing semantics.

Please keep your patch minimal – I'd only want to see changes related to the added dependency in Cargo.lock. Also, some #[cfg()] annotations seem to be unrelated to the actual feature.

[rhaist]

Tried to incorporate all your points - at some point a cargo update might be a good idea ;)