vy commented on code in PR #10: URL: https://github.com/apache/logging-site/pull/10#discussion_r2272660949
########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. Review Comment: I'm a little be reluctant to say **our** BB program: ```suggestion Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for https://yeswehack.com/programs/log4j-bug-bounty-program[YesWeHack Bug Bounty Program]. ``` ########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. -[#threat-common-code-signing] -==== Code signing +[#threat-common-users] +== User types -All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file]. -Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page]. -Thus, GPG signatures should be validated in your build process. +Apache Logging Services distinguishes two kinds of users: -[#threat-common-config-sources] -==== Configuration sources -All configuration sources to an application must be trusted by the programmer. -When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications. -Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees. -This remote location must be kept safe from unauthorized modifications. +Trusted Users:: ++ +Application developers and administrators are considered **trusted** users. +They have unrestricted access to all the features of the logging framework. Review Comment: ```suggestion They have unrestricted access to all the features of the logging framework and the environment it is deployed to. ``` ########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. -[#threat-common-code-signing] -==== Code signing +[#threat-common-users] +== User types -All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file]. -Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page]. -Thus, GPG signatures should be validated in your build process. +Apache Logging Services distinguishes two kinds of users: -[#threat-common-config-sources] -==== Configuration sources -All configuration sources to an application must be trusted by the programmer. -When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications. -Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees. -This remote location must be kept safe from unauthorized modifications. +Trusted Users:: ++ +Application developers and administrators are considered **trusted** users. +They have unrestricted access to all the features of the logging framework. -For Java-based projects supporting JNDI or JMX, -when configurations are modified through JMX, the JMX server should be safely configured to require authentication and a secure connection if being accessed over the network. -When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a Java EE or Jakarta EE application service. -JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure. +Untrusted Users:: ++ +All the other users are considered untrusted. -[#threat-common-java-serialization] -==== Java Object Serialization Stream Protocol +[#threat-common-assets] +== Data sources -https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html[Java Object Serialization Stream Protocol] should not be used to deserialize data from untrusted sources. +Logging systems read data from multiple sources that are controlled by both trusted and untrusted users: + +Trusted Sources:: ++ +* Log4cxx, Log4j and Log4net **trust** environment variables, configuration properties, and configuration files. +To keep them secure: +** It is up to the deployer to ensure that untrusted parties do not have write access to these resources. +** It is up to the deployer to ensure that these resources are transmitted through a confidential channel. +** Non-confidential channels such as HTTP or JMX are disabled by **default** to prevent their unintentional usage. Review Comment: Are we sure everything related with HTTP is disabled across Log4j, Log4net, and Log4cxx by default? ########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. -[#threat-common-code-signing] -==== Code signing +[#threat-common-users] +== User types -All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file]. -Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page]. -Thus, GPG signatures should be validated in your build process. +Apache Logging Services distinguishes two kinds of users: -[#threat-common-config-sources] -==== Configuration sources -All configuration sources to an application must be trusted by the programmer. -When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications. -Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees. -This remote location must be kept safe from unauthorized modifications. +Trusted Users:: ++ +Application developers and administrators are considered **trusted** users. +They have unrestricted access to all the features of the logging framework. -For Java-based projects supporting JNDI or JMX, -when configurations are modified through JMX, the JMX server should be safely configured to require authentication and a secure connection if being accessed over the network. -When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a Java EE or Jakarta EE application service. -JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure. +Untrusted Users:: ++ +All the other users are considered untrusted. -[#threat-common-java-serialization] -==== Java Object Serialization Stream Protocol +[#threat-common-assets] +== Data sources -https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html[Java Object Serialization Stream Protocol] should not be used to deserialize data from untrusted sources. +Logging systems read data from multiple sources that are controlled by both trusted and untrusted users: + +Trusted Sources:: ++ +* Log4cxx, Log4j and Log4net **trust** environment variables, configuration properties, and configuration files. +To keep them secure: +** It is up to the deployer to ensure that untrusted parties do not have write access to these resources. +** It is up to the deployer to ensure that these resources are transmitted through a confidential channel. +** Non-confidential channels such as HTTP or JMX are disabled by **default** to prevent their unintentional usage. +** If configuration files use interpolation features such as +https://logging.apache.org/log4j/2.x/manual/lookups.html[lookups], it is up to the deployer to ensure that only lookups from trusted sources are used. Review Comment: ```suggestion ** If configuration files use interpolation features (e.g., https://logging.apache.org/log4j/2.x/manual/lookups.html[Log4j Lookups]), it is up to the deployer to ensure that only trusted sources are read. ``` ########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. -[#threat-common-code-signing] -==== Code signing +[#threat-common-users] +== User types -All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file]. -Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page]. -Thus, GPG signatures should be validated in your build process. +Apache Logging Services distinguishes two kinds of users: -[#threat-common-config-sources] -==== Configuration sources -All configuration sources to an application must be trusted by the programmer. -When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications. -Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees. -This remote location must be kept safe from unauthorized modifications. +Trusted Users:: ++ +Application developers and administrators are considered **trusted** users. +They have unrestricted access to all the features of the logging framework. -For Java-based projects supporting JNDI or JMX, -when configurations are modified through JMX, the JMX server should be safely configured to require authentication and a secure connection if being accessed over the network. -When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a Java EE or Jakarta EE application service. -JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure. +Untrusted Users:: ++ +All the other users are considered untrusted. -[#threat-common-java-serialization] -==== Java Object Serialization Stream Protocol +[#threat-common-assets] +== Data sources -https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html[Java Object Serialization Stream Protocol] should not be used to deserialize data from untrusted sources. +Logging systems read data from multiple sources that are controlled by both trusted and untrusted users: + +Trusted Sources:: ++ +* Log4cxx, Log4j and Log4net **trust** environment variables, configuration properties, and configuration files. +To keep them secure: +** It is up to the deployer to ensure that untrusted parties do not have write access to these resources. +** It is up to the deployer to ensure that these resources are transmitted through a confidential channel. +** Non-confidential channels such as HTTP or JMX are disabled by **default** to prevent their unintentional usage. +** If configuration files use interpolation features such as +https://logging.apache.org/log4j/2.x/manual/lookups.html[lookups], it is up to the deployer to ensure that only lookups from trusted sources are used. +It is up to the programmer to document thread context keys that can be considered as trusted. Review Comment: This sentence is a little bit dangling. Do we need to briefly explain thread context keys? Isn't it over-specialized to mention it here? ########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. -[#threat-common-code-signing] -==== Code signing +[#threat-common-users] +== User types -All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file]. -Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page]. -Thus, GPG signatures should be validated in your build process. +Apache Logging Services distinguishes two kinds of users: -[#threat-common-config-sources] -==== Configuration sources -All configuration sources to an application must be trusted by the programmer. -When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications. -Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees. -This remote location must be kept safe from unauthorized modifications. +Trusted Users:: ++ +Application developers and administrators are considered **trusted** users. +They have unrestricted access to all the features of the logging framework. -For Java-based projects supporting JNDI or JMX, -when configurations are modified through JMX, the JMX server should be safely configured to require authentication and a secure connection if being accessed over the network. -When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a Java EE or Jakarta EE application service. -JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure. +Untrusted Users:: ++ +All the other users are considered untrusted. -[#threat-common-java-serialization] -==== Java Object Serialization Stream Protocol +[#threat-common-assets] Review Comment: Did you mean `sources`? ```suggestion [#threat-common-sources] ``` ########## _threat-model-common.adoc: ########## @@ -16,31 +16,129 @@ //// [#threat-common] -=== Common threat model += Common threat model -Below we share the threat model shared by all Logging Services projects. +All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx], +https://logging.apache.org/log4j/index.html[Log4j] +and +https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. +The following sections contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data. +Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our +https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program]. -[#threat-common-code-signing] -==== Code signing +[#threat-common-users] +== User types -All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file]. -Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page]. -Thus, GPG signatures should be validated in your build process. +Apache Logging Services distinguishes two kinds of users: -[#threat-common-config-sources] -==== Configuration sources -All configuration sources to an application must be trusted by the programmer. -When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications. -Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees. -This remote location must be kept safe from unauthorized modifications. +Trusted Users:: ++ +Application developers and administrators are considered **trusted** users. +They have unrestricted access to all the features of the logging framework. -For Java-based projects supporting JNDI or JMX, -when configurations are modified through JMX, the JMX server should be safely configured to require authentication and a secure connection if being accessed over the network. -When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a Java EE or Jakarta EE application service. -JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure. +Untrusted Users:: ++ +All the other users are considered untrusted. -[#threat-common-java-serialization] -==== Java Object Serialization Stream Protocol +[#threat-common-assets] +== Data sources -https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html[Java Object Serialization Stream Protocol] should not be used to deserialize data from untrusted sources. +Logging systems read data from multiple sources that are controlled by both trusted and untrusted users: + +Trusted Sources:: ++ +* Log4cxx, Log4j and Log4net **trust** environment variables, configuration properties, and configuration files. +To keep them secure: +** It is up to the deployer to ensure that untrusted parties do not have write access to these resources. +** It is up to the deployer to ensure that these resources are transmitted through a confidential channel. +** Non-confidential channels such as HTTP or JMX are disabled by **default** to prevent their unintentional usage. +** If configuration files use interpolation features such as +https://logging.apache.org/log4j/2.x/manual/lookups.html[lookups], it is up to the deployer to ensure that only lookups from trusted sources are used. +It is up to the programmer to document thread context keys that can be considered as trusted. + +* The logging frameworks **trust** that the objects passed to the log statements can be safely converted to strings: +** These frameworks should not be used to log deserialized data from untrusted sources. See https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data[the related OWASP guide] for details. + +* If parameterized logging is used, the format string is **trusted**: +** Programmers **should** use compile time constants as format strings to prevent attackers from mangling messages. Review Comment: I'm not a native English speaker, but I'd replace `mangling` with `tampering`. (I might very well be wrong.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
