alt Hacker NewsI 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.
Replies
Yep use syslog server or similar in conjuction with this, which basically gives you something like immutability since the data is on a remote server with hopefully different security controls. You really don't want to be trying to sort an attack out after the fact on attacker-controlled machine. They could of course turn off network links or syslog eventually, but you'd at least have the early stages of the attack and or perhaps be able to detect it before they actually get full access.
We need blockchain-esque, WORM-/log-structured filesystems for logs and formal validation of compilers, kernels, and critical bits of userspace. I think a case could be made for a proprietary Flash EEPROM log device "HSM"-like gizmo on a centralized "syslog" box/es that only does one-way writes and authenticated queries.
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. (-:
You’re not wrong, but now you have all your logs on another machine. And that machine could make them immutable/append-only for defense-in-depth purposes :)
I came here to say the same thing; trying to make logs immutable on an attacker-controlled machine feels like a very 2000s-era OpenBSD thing to do.
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.