[HN Gopher] When root meets immutable: OpenBSD chflags vs. log t...
___________________________________________________________________
When root meets immutable: OpenBSD chflags vs. log tampering
Author : todsacerdoti
Score : 124 points
Date : 2025-07-18 08:36 UTC (14 hours ago)
(HTM) web link (rsadowski.de)
(TXT) w3m dump (rsadowski.de)
| johnisgood wrote:
| 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.
| mmsc wrote:
| .bash_history
| mzajc wrote:
| Better yet, `shopt -s 'histappend'` in your .bashrc and
| `chattr +a .bash_history`. This will still allow bash to add
| to the history, but it won't be able to trim the file.
| mmsc wrote:
| Yes! And for macOS, `chflags uappnd .bash_history`
| claviola wrote:
| Are you using systemd-resolved? If so, it's actually a symlink
| to /run/systemd/resolve/stub-resolv.conf, and all you need to
| do to manage it yourself is to turn it into a regular file of
| your own. This is explained in the admittedly very long
| commented out text above the actual directives.
| johnisgood wrote:
| No, it is a runit-based system. I think the issue was related
| to resolvconf + package updates overwriting the file.
|
| That said, I am sure your comment will be useful to some!
| comex wrote:
| > 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?
| TacticalCoder wrote:
| > 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?
| kstrauser wrote:
| 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.
| dgl wrote:
| Except it is sourced from /etc/rc, and that's a shell script
| which obviously depends on the shell and some other pieces.
| If you want an immutable base you kind of need to make the
| whole (base) system immutable (and that is possibly best
| designed as such to start with).
|
| I don't think this is "security vs convenience", I'd more
| argue it's possible to think you've made this secure but
| you've missed something and haven't configured it to be as
| secure as you think. An approach like others have suggested
| with remote logging is at least easier to reason about.
| h43z wrote:
| Do I understand that correctly that in order for logs to rotate
| you have to reboot?
| jelder wrote:
| 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 wrote:
| Log filtering via severity / keywords prevents this, assuming
| the logs are regularly and properly checked.
| gertrunde wrote:
| That would be where something like auditd would come in,
| configured so that if the audit logs location runs low on
| space (or out of space), it will halt the system.
|
| (Yes, quite harsh, but for some use cases it may be the right
| thing to do, i.e. to fail closed).
| louwrentius wrote:
| 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 wrote:
| 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.
| accrual wrote:
| _tsch! tsch! tsch! tsch!_ "Ah, someone is trying to login as
| root again"
| pjmlp wrote:
| Exactly the right approach.
| eternauta3k wrote:
| Is root prevented from directly writing to the underlying block
| device?
| kstrauser wrote:
| Yes.
| messe wrote:
| Only if securelevel is 2. If securelevel = 1, then only
| _mounted_ filesystems are RO. An attacker could conceivably
| forcibly unmount /var/log as root, and make the changes
| directly to the block device.
| dspillett wrote:
| 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 system0, 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 logs1, 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 sinks2, 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
| admins3, 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.
| Rygian wrote:
| 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 wrote:
| 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_. (-:
| anthk wrote:
| Linux has chattr, similar features.
| tptacek wrote:
| 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.
| accrual wrote:
| I enjoyed reading the article, I didn't realize I could have
| this layer of immutability on my OpenBSD systems so easily.
| But after reading the comments here, indeed the real solution
| is to export the logs to a central server in another security
| domain a la PCI requirements.
|
| On the other hand it's great to have documentation like this.
| I feel there's a gradient between convenience and security
| and immutable local logs could provide a layer of defense
| without requiring another server for logging. Maybe a "nice
| to have" for a small homelab, security practice, etc.
| medguru wrote:
| OpenBSD isn't trying anything along those lines. The author
| is. Your statement comes off as an odd and disingenuous
| conflation. They are just file system attributes shared alike
| with Linux and a few other operating systems.
| i80and wrote:
| Without defending this endeavor, is the immutable bit all
| that different from macOS's SIP?
| khaki54 wrote:
| 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.
| stouset wrote:
| 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 :)
| bananapub wrote:
| 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.
| mrtesthah wrote:
| macOS has always had these chflags attributes, by the way, long
| before System Integrity Protection existed. Changing or removing
| the system-immutable/append-only flags required booting into
| single user mode. Even the macOS installer application itself was
| unable to clear them otherwise.
| spauldo wrote:
| That's not surprising given MacOS' lineage.
___________________________________________________________________
(page generated 2025-07-18 23:01 UTC)