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
1. 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.
2. 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)
3. 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.
4. 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
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
-----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
On 09/11/2012 05:54 AM, Rainer Gerhards wrote:
-----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
Thanks Rainer, I missed that point in David's recommendation.
However, I think I might be missing something; this already can be done. It just has to be done locally by the user. As you point out, the user can trust any property he wishes. He just needs to specify it locally. If they wish to reformat the log message objects to put locally trusted objects into a separate container, they are free to do so. They can even had a custom way to do signing, etc. as long as it doesn't clash with the overarching namespace.
IMHO, we should try to avoid adding these "nice to have" features into the spec. Keep it simple and straightforward.
I think we should avoid the conversation of any sort of verifiable trust withing log messages. If this is necessary, the user can always convert the message into XML and use the XML Signature spec.
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
lumberjack-developers mailing list lumberjack-developers@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/lumberjack-developers
lumberjack-developers@lists.fedorahosted.org