-----Original Message----- From: lumberjack-developers-bounces@lists.fedorahosted.org [mailto:lumberjack-developers-bounces@lists.fedorahosted.org] On Behalf Of William Heinbockel Sent: Monday, September 10, 2012 9:28 PM To: lumberjack-developers@lists.fedorahosted.org Subject: Re: [lumberjack] should trusted properties be in a subobject?
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.
I basically agree to all of that, but David mentioned an important point. He hasn't asked for "total trust" but rather "the trust the user has into that". Obviously, we have different trust levels inside the system. If a user wants to say "I trust info from SCM_CREDENTIALS (even though it may be faked)", the local policy can say that this is a trustworthy object. The same goes for mutual-auth TLS protected message exchange. Total trust, of course, you never get. It's all a policy question (even, for example, in healthcare).
So it probably doesn't even make sense to define a default ("trustworthy by default" - dangerous) BUT to provide capabilities to handle custom trust. A separate container would make sense, but here we are again at "flat vs. hierarchical" ;)
Rainer
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
-- William Heinbockel Product Security Team, Red Hat heinbockel@redhat.com