Yet again: there are no difference...

Posted Nov 20, 2011 21:23 UTC (Sun) by khim (subscriber, #9252)
In reply to: That newfangled Journal thing by dlang
Parent article: That newfangled Journal thing

As soon as you send the log remotely, the remote machine can no longer trust the pid

Again: there are no difference between local and remote case. You can trust pid till the "intrusion moment" even if you log remotely and after that moment even local log is suspect.

I still fail to see where you get this weird ideas about local/remote dichotomy.

to post comments

Yet again: there are no difference...

Posted Nov 20, 2011 21:35 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

I am not saying that you can trust it locally, I am just pointing out that the remote machine has no way of knowing if what is sent to it is valid or not. The only way to have the remote machine be able to trust the data it's sent is to have the full TPM lockdown in place (and trust that there is never a flaw that allows it to be broken)

As soon as you go through a second daemon on a local system, you have to trust that that daemon hasn't been broken.

As soon as you read a message from disk you have to trust that the file hasn't been tampered with (and if you hash the file or the messages to try and prevent this, you now have to trust that your store of valid hashes hasn't been tampered with)

I don't know what you wanted to say, but I DO know what you said...

Posted Nov 20, 2011 22:14 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

I am not saying that you can trust it locally,

Rilly? Perhaps my English is failing me, but I thought and that only works on a local machine was quite unambigous...

I am just pointing out that the remote machine has no way of knowing if what is sent to it is valid or not.

That's fair. But as I've noted there a little difference between local and remote case: if you know daemon and kernel are Ok you can trust the logs, if you don't know if they are Ok then you don't. Since the usual way to see if something is broken is to analyze logs, again, and they are available on both local and remote system... no, I don't get your point.

What makes logging over network so special and why can you trust info about pid in local case but not in remote case?

I don't know what you wanted to say, but I DO know what you said...

Posted Nov 20, 2011 22:47 UTC (Sun) by dlang (guest, #313) [Link]

Ok, I should have worded it as "and that only has a chance of working on a local machine"

once you go to another machine, you no longer 'know' anything about what is really generating the message (unless you have crytographic authentication to the sending program, and event that only proves that the sender has access to the key)