When Root Meets Immutable: OpenBSD Chflags vs. Log Tampering
21 comments
·July 18, 2025dspillett
Rygian
That point should not require "reading between the lines" and that's why other standards (e.g. PCI) require explicitly that the logs are sent to a separate "central server" that provides guarantees of immutability.
JdeBP
Indeed. That was exactly what I was thinking when I read the article, from experience of PCI compliance as a matter of fact. And clearly from comments here a lot of people are thinking the same. It may be a fun "Look! OpenBSD can do something!" thing, but the reality is that defence against the dark arts goes a lot deeper, and (as ever) one often has to read more than one standard/specification. (-:
johnisgood
It is not the same, but I do use "chattr +i" on a file (which applies the immutable attribute) on Linux to a file that otherwise would have been overwritten by programs that do not give a damn whether I want it to or not, and in my case it was easier to just make that file immutable, mainly: /etc/resolv.conf.
knorker
Yeah chattr is a very useful weapon against the strongly but incorrectly opinionated mandates of systemd.
I'm just waiting for systemd to start clearing chattr bits because "the user's intentions are bad and they should feel bad".
johnisgood
That actually does not sound too far-fetched. I believe there is a high chance that it might eventually happen, at least to files systemd """cares""" about.
comex
> Once the system reaches normal security level, even root cannot tamper with these logs without rebooting into single-user mode
What stops the attacker from just editing /etc/rc.securelevel and then doing a normal reboot?
kstrauser
Make that file immutable so that you can only edit it in single-user mode.
This is definitely one of those “security vs convenience” situations where you can easily shoot yourself in the foot, but it’s great to have the option when you need it.
TacticalCoder
> What stops the attacker from just editing /etc/rc.securelevel and then doing a normal reboot?
Certainly a full reboot leaves more tracks than no full reboot? So it's harder to hide?
h43z
Do I understand that correctly that in order for logs to rotate you have to reboot?
jelder
My thoughts exactly. And couldn’t an attacker just fill the logging volume with uninteresting events to prevent certain other events from being recorded?
jorvi
Log filtering via severity / keywords prevents this, assuming the logs are regularly and properly checked.
null
louwrentius
If you want immutable logs, you log to an external log server. Anything else seems security theater to me.
That log server is properly firewalled/hardened so a hacked server can’t be used as a stepping stone to compromise the log server.
Maybe you even have access restrictions in place for the log server so people can’t wipe their own misdeeds (4-eyes principle).
This is how it’s been done for 35+ years, nothing special about this.
holowoodman
Yes, so much this. It used to be that important logs (filtered by severity and keywords) were even continuously live-printed by a line printer, so that there was always a current paper copy of the really important stuff for forensics.
See e.g. https://www.youtube.com/watch?v=FiEGoVzmyvs but dot-matrix was also used and at least a little less noisy.
eternauta3k
Is root prevented from directly writing to the underlying block device?
bananapub
immutable is a handy advisory feature, but the actual answer for log tampering is "get them off the box in to a different security domain", e.g. a log server this machine can't access and is securely backed up so logs that make it there can be fairly well trusted.
I feel this is fixating on the wrong problem. Even with immutable flags there are various ways an attacker with root access could, after getting what they want from the system, cover their tracks by trashing the whole system⁰, and as usual if someone has physical access all bets are off. I see filesystem level flags like that to be more tools to stop you or a bug accidentally doing something stupid, than to get in the way of a malicious action by someone else.
While the standard might effectively call for immutable logs¹, he needs to read between the lines one step further: those logs do not need to be on the same machine. You could stream logs to another system that stores them immutably from the PoV of anyone except those with root or physical access to it. You still have a problem if an attacker gets access to both the source system(s) and the log sinks², there might be a latency issue meaning you could easily lose the last few log entries in the case of a complete disaster, and you have an extra moving part in your infrastructure to monitor, but it satisfies the requirement where immutable filesystem flags can not.
----
[0] Yes, you'll know something happened, and you might guess it was malicious and not random corruption, but enough tracks might be covered to stop you working out the initial who & how.
[1] and some standars explicitly call for them
[2] Careful granular access management should largely mitigate that risk. That could be a problem if you are a small organisation trying to protect against internal disgruntled admins³, but you could use a a 3rd party log-sink service in that case.
[3] This may seem overly paranoid, but if it is required for the standard your target audience wants you to have a certificate for…, and TBH it isn't that paranoid.