Credential file not covered by the baseline: ‹path›
What this means
‹path› — one of the two root-only credential/privilege files Bulwark tracks (/etc/shadow, /etc/sudoers) — is present but has no baseline hash, so its integrity is unverifiable. This is the specific gap that made the old logic dangerous: a baseline recorded without --privileged never contains these two files, so a later privileged scan would hash them, find them “not baselined”, and report nothing — the two most security-critical files on the host reading as clean when they had never actually been checked. Rated above info because these two files, unlike an ordinary config, are exactly where credential tampering hides.
How to fix it
Run sudo bulwark fim baseline --privileged while you trust this host, to record a known-good hash for /etc/shadow and /etc/sudoers.
Check it yourself
Run a scan and look for BLWK-FIM-006 in the results:
bulwark scanInstalled the standalone CLI package instead of the app? The command is bulwarkctl.
How Bulwark decides
Bulwark reads file_integrity_privileged and reports this check when:
in_baseline == false and currently_present == true and unreadable == falseIf a value can't be read, Bulwark reports the check as undetermined rather than passing it. View the rule source.
References
Related checks
- Shell history recording is suppressed ·
BLWK-EVASION-001 - File modified since baseline: ‹path› ·
BLWK-FIM-001 - File deleted since baseline: ‹path› ·
BLWK-FIM-002 - Not covered by the file-integrity baseline: ‹path› ·
BLWK-FIM-003 - Credential file modified since baseline: ‹path› ·
BLWK-FIM-004 - Credential file deleted since baseline: ‹path› ·
BLWK-FIM-005