David,
There was a lumberjack thread several weeks ago that discussed trusted properties. At the conclusion of that thread, I recall the general concensus being that there is no such thing as a "trusted property" given today's logging infrastructure
One problem is that there is no secure route by which we can guarantee that an property is genuine and can be "trusted". From the perspective of a log daemon (e.g., syslog) it can say the external data it received, and add what it is told is the system time, pid, etc. However, there is no way that I am aware of to say that (1) this property is valid and (2) we can verify the value's integrity after the event has been logged.
To even start down this road, the subobject would have to be signed and stored/transmitted via some sort of integrity-protected log store or message format, whereby the data added is signed by the process adding it. Then we need to discuss how the signing keys are generated, used, shared, and protected so that a trusted property can be verified.
Additionally, you would have to allow for nested subobjects and handle the cases where a new device wants to append new data to an already trusted object.
On 09/10/2012 03:13 PM, david@lang.hm wrote:
should the trusted properties be grouped into a subobject (i.e. trusted!pid, trusted!uid, etc)?
I think that the answer is yes for the following reasons
- there may be multiple PID objects. For examplthe syslogtag includes a PID.
It's useful to have both what the application claims and what the system claims and be able to compare the two.
- when relaying from one machine to another, the trusted properties need to be
handled specially depending on the degree of trust that the transport protocol provides (and that the sysadmin places on that trust)
- there needs to be some protection to prevent people from generating logs that
have the trusted properties in them. This is easier if these are in one object and you can protect that object than if they are a bunch of individual properties that have to be protected seperately.
- If there is a trusted subobject, it's easier to extend. For example, when
logs are being relayed from one system to another, the recieving system can add items into the trusted subobject to provide information about the connection. For example, it could add certificate information or the remote IP address of the sending machine.
I would define this trusted object as something like:
Fields in the Trusted object should be generated by the software recieving the log messages and MUST not be able to be affected by anything that the application generating the log puts into the log message.
Applications recieving relayed log messages SHOULD update the Trusted object to identify if the data should still be trusted.
Applications recieving relayed log messages MAY update the Trusted object with additional information indicating why the fields should still be trusted.
Thoughts?
David Lang _______________________________________________ lumberjack-developers mailing list lumberjack-developers@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/lumberjack-developers