5 ms·

That comment is insane. Why would log files need journaling? They should be serialized. How is adding a line to a run script "duplicating logic badly"? Coup

That comment is insane. Why would log files need journaling? They should be serialized. How is adding a line to a run script "duplicating logic badly"? Coupling is clearly bad, as evidenced by ... 30+ years of software design, but is a necessary evil. I don't see any reason why it's necessary in such a low level system component. "this is not rocket science" you don't impose dependencies on something you want to be reliable. Daemontools is clearly the most mature solution, from a perspective of stability. It's probably why nobody wants to use it, there's nothing to play with or exploit for profit because it already works.

bitwize 13y ago
That comment is insane. Why would log files need journaling? They should be serialized. systemd-journald provides tampering-attestation features that plain-text logs do not, and cannot, provide. It's fundamentally more secure.
- peterwwillis 13y ago
  Fallacy: having owned the user that writes logs, I cannot fuck with your logs if journaled. Reality: if I owned the user writing logs, I can do anything I want with the logs, no matter how they're stored.
  - hdevalence 13y ago
    No, you cannot do anything you want with the logs. Here is something you cannot do: you cannot alter the logs without anyone noticing, since log entries have a rolling hash. This prevents an attacker from being able to modify logs without detection, and was implemented in systemd after the postmortem on the kernel.org breakin, i.e., it was developed to counter an actual threat. I would suggest you read up on what log attestation actually does.
    - peterwwillis 13y ago
      Logs can be modified in real time by being intercepted during writes to the buffer before the new hash is applied. Because of this, only the logs up to the intrusion can be preserved, and even then if the old message/hash/key/etc is still in memory, the old messages can be modified. The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.
      - bct 13y ago
        > The only truly secure way to record messages up to the point of break-in is a one-way remote log. And if you have this then you don't need a fancy cryptographic syslogd to detect tampering.
        peterwwillis 13y ago
        The fancy cryptologic syslogd is fallible as I mentioned previously, so why depend on it? And really if you really want to cover your tracks you can just cause random disk corruption over the whole disk (and just happen to damage the journal in the process). Things will start failing rapidly, fsck will later show itself fixing the disk corruption, and it will be assumed to be a hardware error and the incident ignored. Security half-measures do not mean you are secure. If it can be hacked, it will be hacked, and then what was the point of sacrificing your whole system's init system? (Also you could just replace syslogd with a journaled syslogd, rather than replacing your entire init system... but I guess that's off-topic?)
        bct 13y ago
        I'm agreeing with you.
    - Fasebook 13y ago
      >rolling hash FAIL. You just wrote outdated software. Under this dumbass idea of journaling, which by defition is there to allow editing.., the best thing you can do is built a rolling function, which basically means coping the data, which basically means increasing your attack surface.
  - asabjorn 13y ago
    From what I understand systemd can optionally store a copy of the logs on a remote server. The key to modify the logs on the remote server is changed in such a way that even if a system is compromised the log copy on the remote system can not be changed. These remote copies of the logs could actually be used to detect log-tampering and 0day exploits.
    - Fasebook 13y ago
      >From what I understand systemd can optionally store a copy of the logs on a remote server. anything can have any feature, what matters is how it's built.
  - andor 13y ago
    The journal sealing provides forward security. The sealing keys are exchanged regularly, and the old keys are deleted safely. A verification key, which is stored on another device or offline, can be used to calculate the sealing key for any given moment. While an attacker can change the logs, this will always be visible in an audit. http://lwn.net/Articles/512895/ http://lwn.net/Articles/512895/ https://eprint.iacr.org/2013/397.pdf https://eprint.iacr.org/2013/397.pdf
    - d0 13y ago
      the old keys are deleted safely Assuming nothing has managed to redirect those unlinks for example...
      - andor 13y ago
        I guess you're right. The mechanism is forward-secure, which means for an attacker that tampering the logs is the first thing to do, not the last ;-) As soon as the attacker manages to extract the state of the key generator from memory at one point of time, the log entries from that and the following sealing periods can be modified and cleanly sealed.
- edwintorok 13y ago
  rsyslog allows you to sign your logs if you want to: http://www.rsyslog.com/how-to-sign-log-messages-through-signature-provider-guardtime/ http://www.rsyslog.com/how-to-sign-log-messages-through-sign...

bitwize 13y ago

That comment is insane. Why would log files need journaling? They should be serialized. systemd-journald provides tampering-attestation features that plain-text logs do not, and cannot, provide. It's fundamentally more secure.

peterwwillis 13y ago
Fallacy: having owned the user that writes logs, I cannot fuck with your logs if journaled. Reality: if I owned the user writing logs, I can do anything I want with the logs, no matter how they're stored.
- hdevalence 13y ago
  No, you cannot do anything you want with the logs. Here is something you cannot do: you cannot alter the logs without anyone noticing, since log entries have a rolling hash. This prevents an attacker from being able to modify logs without detection, and was implemented in systemd after the postmortem on the kernel.org breakin, i.e., it was developed to counter an actual threat. I would suggest you read up on what log attestation actually does.
  - peterwwillis 13y ago
    Logs can be modified in real time by being intercepted during writes to the buffer before the new hash is applied. Because of this, only the logs up to the intrusion can be preserved, and even then if the old message/hash/key/etc is still in memory, the old messages can be modified. The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.
    - bct 13y ago
      > The only truly secure way to record messages up to the point of break-in is a one-way remote log. And if you have this then you don't need a fancy cryptographic syslogd to detect tampering.
      - peterwwillis 13y ago
        The fancy cryptologic syslogd is fallible as I mentioned previously, so why depend on it? And really if you really want to cover your tracks you can just cause random disk corruption over the whole disk (and just happen to damage the journal in the process). Things will start failing rapidly, fsck will later show itself fixing the disk corruption, and it will be assumed to be a hardware error and the incident ignored. Security half-measures do not mean you are secure. If it can be hacked, it will be hacked, and then what was the point of sacrificing your whole system's init system? (Also you could just replace syslogd with a journaled syslogd, rather than replacing your entire init system... but I guess that's off-topic?)
        bct 13y ago
        I'm agreeing with you.
  - Fasebook 13y ago
    >rolling hash FAIL. You just wrote outdated software. Under this dumbass idea of journaling, which by defition is there to allow editing.., the best thing you can do is built a rolling function, which basically means coping the data, which basically means increasing your attack surface.
- asabjorn 13y ago
  From what I understand systemd can optionally store a copy of the logs on a remote server. The key to modify the logs on the remote server is changed in such a way that even if a system is compromised the log copy on the remote system can not be changed. These remote copies of the logs could actually be used to detect log-tampering and 0day exploits.
  - Fasebook 13y ago
    >From what I understand systemd can optionally store a copy of the logs on a remote server. anything can have any feature, what matters is how it's built.
- andor 13y ago
  The journal sealing provides forward security. The sealing keys are exchanged regularly, and the old keys are deleted safely. A verification key, which is stored on another device or offline, can be used to calculate the sealing key for any given moment. While an attacker can change the logs, this will always be visible in an audit. http://lwn.net/Articles/512895/ http://lwn.net/Articles/512895/ https://eprint.iacr.org/2013/397.pdf https://eprint.iacr.org/2013/397.pdf
  - d0 13y ago
    the old keys are deleted safely Assuming nothing has managed to redirect those unlinks for example...
    - andor 13y ago
      I guess you're right. The mechanism is forward-secure, which means for an attacker that tampering the logs is the first thing to do, not the last ;-) As soon as the attacker manages to extract the state of the key generator from memory at one point of time, the log entries from that and the following sealing periods can be modified and cleanly sealed.
edwintorok 13y ago
rsyslog allows you to sign your logs if you want to: http://www.rsyslog.com/how-to-sign-log-messages-through-signature-provider-guardtime/ http://www.rsyslog.com/how-to-sign-log-messages-through-sign...