Systemd To Secure Logs With "Forward Secure Sealing"

[phoronix]

Phoronix: Systemd To Secure Logs With "Forward Secure Sealing"

Systemd has picked up a new feature -- Forward Secure Sealing (FSS) -- in an attempt to better secure system logs on the local file-system in the event a hacker penetrates the system the logs cannot be modified...

http://www.phoronix.com/vr.php?view=MTE2NDk

[uid313]

Git

Git also use something similar. It hash the hashes or something.

[wpoely86]

What is stopping the attacker from changing the logs and resealing the logs (as the key is on the local machine)?

[tettamanti]

What is stopping the attacker from changing the logs and resealing the logs (as the key is on the local machine)?

The sealing key changes with time (15m by default) and the old key is securely erased; the algorithm is designed so that given K(t) is easy to compute K(t+1) (i.e. the new key), but it's not possible to compute K(t-1) given K(t) (i.e. it's not possible to compute the "old" key given the current one). The starting point K(0) is derived from the verification key (which is not stored on the machine), and using the verification key it's possible to generate K(t) for any t.
An attacker could tamper with the last portion of the log, the one cover with the key currently stored on the system, but cannot alter the past checkpoints (seals) since he is unable to compute the older keys (including K(0)).

[VinzC]

With all due respect to Lennart, I don't get all this security through cryptography that's going on. I'm rather sceptic, not that I refuse to admit anything but I'm finding the current security "trend" rather scary.

As far as logs are concerned, why go with cryptography exactly? To me logs are append-only to the very least. Why not "invent" a new filesystem (e.g. yalogfs) that would accept files to be opened only in "append" mode or be truncated? (?You can kill me but you cannot alter me!?) I'm thinking of it roughly but I would love to keep things as simple as can be and introducing cryptographic keys for just log files seems a little... overkill to me. (What if I lose the most important key, for instance?)

I'm pretty sure it's still possible to achieve using common solutions, even if they need to be tuned, like in my suggestion. For instance, log files could be syslogged to a secondary machine, which archives them at once. Of course this would mean all services must support syslog but I guess it's not a big deal, right? And one might object syslog is sending in clear form, okay, but there are also VLANs (for instance) or secure tunnels to prevent wiretapping, right?

I mean securing log files doesn't necessarily *require* encryption, does it? Especially knowing that cryptography or not, there'll *always* be (IMHO) one way at least to alter a system without the sysadmin's consent, no matter how protected it is -- he, hacker, who will is going to find a way. Call me an idiot otherwise, no problem ;-).

[Flyser]

As far as logs are concerned, why go with cryptography exactly? To me logs are append-only to the very least. Why not "invent" a new filesystem (e.g. yalogfs) that would accept files to be opened only in "append" mode or be truncated? (?You can kill me but you cannot alter me!?) I'm thinking of it roughly but I would love to keep things as simple as can be and introducing cryptographic keys for just log files seems a little... overkill to me. (What if I lose the most important key, for instance?)

Actually what you describe one of grsecuritys most basic features.
The problem with "your solution" is that on an unprotected linux system (no selinux, grsecurity or other means to prevent full root access) the attacker might just read and write to the block device directly.

[uid313]

?You can kill me but you cannot alter me!?

Oh, that's pretty cool.

[VinzC]

Actually what you describe one of grsecuritys most basic features.

Sounds reassuring to be not the first one who has thought of that . Thanks a lot for the info.

The problem with "your solution" is that on an unprotected linux system (no selinux, grsecurity or other means to prevent full root access) the attacker might just read and write to the block device directly.

Well, protection systems are there to protect the unprotected, then, right? I personally have nothing against the idea that you would need to install a "security kit" (provided you understand it, of course) if you need an extra bit of security. Not every system needs such a high level of security IMHO given that it's still pretty "straightforward" (read "documented") to secure a Linux system to offer an acceptable compromise between admin nightmare and vulnerability in most cases, right?

[wpoely86]

Actually what you describe one of grsecuritys most basic features.
The problem with "your solution" is that on an unprotected linux system (no selinux, grsecurity or other means to prevent full root access) the attacker might just read and write to the block device directly.

Even on a protected linux system, if the attacker gains root somehow, what is stopping him from writing to the block device directly? You would still need something like this FSS to be sure?

[LightBit]

The worst thing attacker can do, is modify your logs?

A lot of complexity for tiny (or no) security improvement.