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 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.

[energyman]

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)).

so if the key changes every few minutes, how do keep the other key a) seperate b) without of reach and c) still up to date?

Sounds... not very secure.

Either way, a guy has root access you are toast.

[tettamanti]

so if the key changes every few minutes, how do keep the other key a) seperate b) without of reach and c) still up to date?

The verification key ("other") is generated only once at system setup and is never altered.

Either way, a guy has root access you are toast.

The point is to ensure the integrity of the logs *up to* the intrusion, once the attacker has gained root privileges all the data must be considered untrusted.

[grantek]

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)).

So couldn't an attacker log on, grab K(t) from wherever it's currently stored, be evil for several hours, then go back and re-write the log verbatim until the start of K(t), then (with knowledge of how to compute all keys after K(t)) rewrite an altered log from then onwards?

It might be a bit more secure if a key change was initiated upon each login, but an attacker could still hide all activity after that, and make their login look legitimate.

It might also be a bit more secure if the log is fully encrypted and unreadable on the local host, which would force the attacker to guess what a legitimate log could look like.