4 ms·

On a compromised system you can't trust any file stored on the system. Be it text log files or binary log files. The person who compromised the system will just

On a compromised system you can't trust any file stored on the system. Be it text log files or binary log files. The person who compromised the system will just dump the entire binary store instead, which is normally what happens to text log files. I use many commands (grep, tail, head, etc) to view and parse log files daily. And storing the files will just add complexity to a very simple system. Now I don't disagree that syslog needs some further advancements for access control/management. I may just be not thinking a head and what else could be possible; but I just see this interrupting my normal workflow for debugging issues.

dredmorbius 15y ago
Cryptography, properly applied, allows you to verify file integrity. The real problem becomes one of key management however -- if the Journal proposal solves this issue (and it's not a simple one) then it's possible that the "has the integrity of my system logs been preserved/maintained" question can be answered. Managing keys properly is highly non-trivial, especially on a system in which you want those keys to be available/accessible automatically at boot. Since the proposal works via signing (hashing) rather than decrypting, PKI could be used, but I still smell issues.
- jerf 15y ago
  Cryptography allows you to verify that somebody who does not possess your private key did not modify the file. A hacker on the same system as a syslogger has the private key of the syslogger. They can "simply" (for varying values of simply) replay the logs again, only with whatever events they want filtered out or modified, and it will pass the crypto checks just fine. You have to offload your logs somewhere else, at which point the whole encryption in the logs themselves are sort of redundant. Managing keys in this case isn't just "highly non-trivial", it's flat out impossible.
  - dredmorbius 15y ago
    Using PKI, this isn't necessarily true. Even constructing a system with simple one-way hashes might be sufficient. If the logging system is based on a hash of the current and prior records, you get chaining and integrity validation prior to the attack (one problem of attacks is wiping out immediate or all prior history). If you've got remote storage / logging, particularly on multiple systems with independent trust models (compromising system A doesn't necessitate compromise of B and/or C), you're in better shape still. A signature which required periodic updating of a key from a key provider via a mechanism that prevents later key reuse would mean that past records couldn't be fabricated or modified after the fact. This might require passing data through two or more systems to accomplish the signing in a trusted fashion (not particularly amenable to high-rate logging). The verification key need not be on the logging system at all (and ideally wouldn't be). You'd access and verify logs from a standalone hardened and highly trusted system (say: booted from known good static media). Much of which is good for the extreme case, but as I note in my other comments, isn't particularly practical for day-to-day needs. Which means it's also likely to be unfamiliar to technical staff, rarely practiced, rarely exercised, and buggy.
    - jerf 15y ago
      If they are on the box and you don't have your logs offloaded, they can at the very least destroy the logs, and barring your complicated key updating system which would itself require lots of careful review, probably forge anything they want. But destruction is a pretty useful capability itself. If the logs are being offloaded off the system, then you don't need any of this either because they are already being put somewhere the hacker can't touch. (Of course if they hack that system then you're in real trouble, but that's just moving the problem around; ultimately if your hacker owns everything, you've really, really lost.) There's no inbetween state where all this complexity solves any problem. Either you've got off-box storage and you don't need it, or you don't and you've already lost if a hacker gets root.
      - dredmorbius 15y ago
        I agree with your points here. I don't see the proposed journal solution really solving on-system log integrity. There are a few other points (processes impersonating other processes, e.g., or extended logging formats) which might be better supported in something other than a traditional syslog. But I'm absolutely not sold on Journal.

dredmorbius 15y ago

Cryptography, properly applied, allows you to verify file integrity. The real problem becomes one of key management however -- if the Journal proposal solves this issue (and it's not a simple one) then it's possible that the "has the integrity of my system logs been preserved/maintained" question can be answered. Managing keys properly is highly non-trivial, especially on a system in which you want those keys to be available/accessible automatically at boot. Since the proposal works via signing (hashing) rather than decrypting, PKI could be used, but I still smell issues.

jerf 15y ago
Cryptography allows you to verify that somebody who does not possess your private key did not modify the file. A hacker on the same system as a syslogger has the private key of the syslogger. They can "simply" (for varying values of simply) replay the logs again, only with whatever events they want filtered out or modified, and it will pass the crypto checks just fine. You have to offload your logs somewhere else, at which point the whole encryption in the logs themselves are sort of redundant. Managing keys in this case isn't just "highly non-trivial", it's flat out impossible.
- dredmorbius 15y ago
  Using PKI, this isn't necessarily true. Even constructing a system with simple one-way hashes might be sufficient. If the logging system is based on a hash of the current and prior records, you get chaining and integrity validation prior to the attack (one problem of attacks is wiping out immediate or all prior history). If you've got remote storage / logging, particularly on multiple systems with independent trust models (compromising system A doesn't necessitate compromise of B and/or C), you're in better shape still. A signature which required periodic updating of a key from a key provider via a mechanism that prevents later key reuse would mean that past records couldn't be fabricated or modified after the fact. This might require passing data through two or more systems to accomplish the signing in a trusted fashion (not particularly amenable to high-rate logging). The verification key need not be on the logging system at all (and ideally wouldn't be). You'd access and verify logs from a standalone hardened and highly trusted system (say: booted from known good static media). Much of which is good for the extreme case, but as I note in my other comments, isn't particularly practical for day-to-day needs. Which means it's also likely to be unfamiliar to technical staff, rarely practiced, rarely exercised, and buggy.
  - jerf 15y ago
    If they are on the box and you don't have your logs offloaded, they can at the very least destroy the logs, and barring your complicated key updating system which would itself require lots of careful review, probably forge anything they want. But destruction is a pretty useful capability itself. If the logs are being offloaded off the system, then you don't need any of this either because they are already being put somewhere the hacker can't touch. (Of course if they hack that system then you're in real trouble, but that's just moving the problem around; ultimately if your hacker owns everything, you've really, really lost.) There's no inbetween state where all this complexity solves any problem. Either you've got off-box storage and you don't need it, or you don't and you've already lost if a hacker gets root.
    - dredmorbius 15y ago
      I agree with your points here. I don't see the proposed journal solution really solving on-system log integrity. There are a few other points (processes impersonating other processes, e.g., or extended logging formats) which might be better supported in something other than a traditional syslog. But I'm absolutely not sold on Journal.