Lion Cipher Lab
Seal your logs against a root attacker — journald Forward Secure Sealing (FSS)
- Cyber / Security Engineer
- Advanced
- 60-75 minutes
- Free · no account required
Why it matters
The uncomfortable truth about local logs is that the account they are meant to hold accountable — root — is also the account that can rewrite them. Ordinary file permissions are no defence: root owns the files. An attacker who reaches root can open journald's binary journals, delete the lines that record their intrusion, and leave a log that reads as if nothing happened. Forward Secure Sealing is systemd's built-in answer to exactly that move. It cannot stop root from editing the file, but it makes any edit to already-sealed history mathematically detectable, and 'forward secure' means the…
What you'll learn
- making the systemd journal persistent and understanding why volatile storage defeats sealing
- generating an FSS key pair with journalctl --setup-keys and reading its output
- explaining the FSS key split: the on-box sealing key that evolves vs the off-box verification key
- turning on sealing (Seal=yes) and proving journal integrity with journalctl --verify
- tampering with a sealed binary journal as root and detecting it cryptographically, down to the byte offset
- reading a --verify failure precisely (Tag failed verification, byte offset, the --verify-key requirement)
- articulating tamper-EVIDENCE vs tamper-PREVENTION and the forward-security guarantee
- knowing where FSS ends and off-box log shipping (WORM / remote collector) has to begin
Steps in this lab
- The threat, and what sealing can and cannot do
- Make the journal persistent — or you are sealing sand
- Generate the FSS key pair — and understand the split
- Turn sealing on and confirm it is live
- Attack your own logs: tamper a sealed byte, watch verify catch it
- Read the failure precisely, and know the named ways it goes wrong
- Judgment: where FSS fits, the interval tradeoff, and when not to bother