When Root Meets Immutable: OpenBSD Chflags vs. Log Tampering

Summary

Why ISO 27001 Demands Immutable Logs (Without Actually Saying So) # ISO 27001 is like that careful lawyer who never says exactly what they mean – it tells you what needs to be achieved, not how to do it. When it comes to logging, this is particularly telling: Control A.12.4.2 simply states that “logging information and logging facilities shall be protected against tampering and unauthorized access.” Period. How? That’s your problem to solve. But anyone who’s ever had to investigate a security incident knows the harsh reality: logs are only as trustworthy as their protection against post-incident tampering. An attacker who gains root access isn’t going to politely leave their tracks in the log files – unless they physically can’t alter them anymore. Anyone who follows this blog knows I’ve been diving into VFS/FFS code lately, and during that exploration, I stumbled across SF_APPEND and SF_IMMUTABLE flags in the kernel source. “IMMUTABLE?” I thought. “What the hack, OpenBSD can do that? Must be dead code ;)”. Turns out these flags are very much alive and can be beautifully set using chflags. I started playing around with them in /tmp, and for days afterward, I’d get a bunch of error messages on every boot because OpenBSD, as you know, cleans /tmp on startup. I left it like that for a while – just another quirky reminder of my filesystem experiments. Then a client I administrate several OpenBSD servers for asked me about ISO 27001 compliance. Suddenly, those “dead” immutable flags didn’t seem so useless anymore. In fact, they turned out to be exactly what the standard was asking for, even if it doesn’t explicitly say so. This is where immutability becomes not just a nice-to-have, but a forensic necessity. While ISO 27001 never mentions the word “immutable”, it’s essentially describing exactly that: logs that cannot be modified after they’re written. This isn’t security theater – it’s about maintaining the integrity of your audit trail when it matters most. But there’s ...