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.
↫ Rafael Sadowski
It turns out OpenBSD has a few relatively simple tools to make logs immutable, in a way that not even root can delete or modify them, or change any of the logging schedules. Reading through the blog post, you don’t even need a ton of intricate knowledge to set this up, thanks mostly to just how much innate sense OpenBSD tends to make, and how excellent the documentation is.
I have no need for this level of security, but if you do, you can set this up in a few minutes.
Stopped bad actors from covering their tracks is an important aspect of security. This is really good to see.
I can also see this becoming a requirement for certain classes of compliance. Being able to prevent “internal” bad actors from covering their tracks can be equally important.
I know Linux can also do the append/immutable thing with
chattr
(+a or +i) but it’s been too long and I can’t remember what the Linux way was to strip root of the permission to unset those flags.Cool.
But it doesn’t protect against tampering with raw local disk when OpenBSD is _not running. If possible, configure your syslogd to send copy sensitive syslog messages to remote servers. That way bad actors will have to chase down their tracks to remote systems.
This is what disk encryption is for. OpenBSD supports full disk encryption in the installer so when the OS is not running, it can’t be accessed even by physically putting the drive in another computer. Besides, if you’re at the point where your attacker has physical access to the drive itself, modified logs are the least of your worries.
Morgan,
A hardware based TPM can make it harder to move the disk, but a weakness of this approach is that the hardware is basically oblivious to software exploits A TPM isn’t going to differentiate between proper and improper requests from the OS under the admin’s control.
Maybe we could have a kernel that disables root completely, using only the “capabilities” bit mask for admin purposes. I don’t know if this really solves the root problem though (haha). If we have a compromised admin account that assigns capabilities, then the attacker can use it to grant themselves more access.
I guess you could create a system that lacks a local admin capability altogether. and the kernel would only accept requests that are signed by an upstream admin. Do you know of an operating system that works like this?
I was specifically referring to @ponk’s example of accessing the disk when OpenBSD isn’t running. After you set up full disk encryption on an OpenBSD volume during installation, when you boot the disk you have to provide a passphrase to decrypt the entire disk before the OS itself will boot. Effectively, when OpenBSD is not booted the disk is encrypted and cannot be read by another OS. The TPM (if even present) never comes into play. Sorry for any confusion.
Morgan
Ah, so you are talking about a desktop environment? I read ponk’s comment in the context of servers where we generally don’t have the luxury password protecting hard disks on servers.
Assuming we have a server/device that is expected to auto boot non-interactively, then it rules out purely software based solutions that require interactivity. The encryption keys that the server needs to boot normally must be must be made available to the server and stored in the clear (even if security through obscurity is used). TPM modules can help with this, among other things.
We’re all talking about slightly different use cases. the author intended to include immutability protection against root, which would even include someone with the password, but IMHO that’s a really a difficult standard to uphold.
@Alfman:
I assumed @ponk was speaking of servers too; you can enter OpenBSD’s disk encryption passphrase via out of band management like IPMI on bare metal or NoVNC on virtual servers.
Morgan,
Well you got me there, I concede things like IPMI and VM remote consoles will let a remote admin connect in as though they are sitting at the local console. But IMHO that doesn’t really make it more desirable to have servers block on an interactive login so they can finish boot up. There may be some cases where an interactive login may be ok, like a personal media server, but most of the time we want servers to be automated. Imagine a VPN/router/security cam/home automation/etc server where you might want encrypted disks but you certainly don’t want the server to sit there waiting for a login before it can function.
I don’t think most users need TPM, but nevertheless it’s scenarios like this where TPM offers an advantage over pure software solutions.
ponk,
I was thinking the same thing. Once a skilled adversary has root, it becomes really hard to cage them. You’re right that if the attacker has raw access to the local disk, it’s already game over, but I think the article assume the attacker is remote and doesn’t have raw disk access.
Even if we invent new file system permissions to impede root, root still holds so many cards. Root can load modules that change the system behavior. Sometimes root can access raw system memory. Usually root still has access to the raw disk even though it’s mounted. Root may be able to kexec into their own kernel. If nothing else, root typically has the ability to update the system = game over. Even if we somehow closed all conceivable ways to bypass immutability (and do so without interfering with normal admin), root still has other tricks. By controlling the date and daemons, root may be able to get the logs to roll around and erase themselves normally.
I agree with you, at best this is a poor man’s solution. If it’s really that important that logs be preserved beyond the reach of a root user, then they really should be stored externally to the system under root’s control.
As the article mentions the Immutable flag exists in ZFS. Solaris originally picked that up from FreeBSD UFS and then it arrived back in FreeBSD ZFS. I wrote about Immutable on Solaris back in 2008 https://blogs.oracle.com/solaris/post/making-files-on-zfs-immutable-even-by-root
Since then in Solaris ZFS we have added File Retention which is an “immutable until a future date”, this is enforced deep inside the ZFS kernel module and prevents the file system and pool from being deleted if there are retained files. https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/retaining-your-files.html