Page 1 of 4 123 ... LastLast
Results 1 to 10 of 31

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,812

    Default Systemd To Secure Logs With "Forward Secure Sealing"

    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

  2. #2
    Join Date
    Dec 2011
    Posts
    2,048

    Default Git

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

  3. #3
    Join Date
    Aug 2010
    Posts
    48

    Default

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

  4. #4
    Join Date
    Jan 2009
    Location
    Italy
    Posts
    82

    Default

    Quote Originally Posted by wpoely86 View Post
    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)).

  5. #5
    Join Date
    Jun 2009
    Location
    Elsewhere
    Posts
    90

    Default

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

  6. #6
    Join Date
    Mar 2010
    Posts
    33

    Default

    Quote Originally Posted by VinzC View Post
    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.
    Last edited by Flyser; 08-21-2012 at 10:25 AM.

  7. #7
    Join Date
    Dec 2011
    Posts
    2,048

    Default

    Quote Originally Posted by VinzC View Post
    «You can kill me but you cannot alter me!»
    Oh, that's pretty cool.

  8. #8
    Join Date
    Jun 2009
    Location
    Elsewhere
    Posts
    90

    Default

    Quote Originally Posted by Flyser View Post
    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.

    Quote Originally Posted by Flyser View Post
    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?

  9. #9
    Join Date
    Aug 2010
    Posts
    48

    Default

    Quote Originally Posted by Flyser View Post
    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?

  10. #10
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

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

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •