ppkarwasz commented on code in PR #10: URL: https://github.com/apache/logging-site/pull/10#discussion_r2273256198
########## _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: For Log4j, `http` is not enabled by default for retrieving configuration files. Only `file`, `jar`, and `https` are allowed by default via the [`log4j2.configurationAllowedProtocols`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationAllowedProtocols) system property. Additionally, the classpath and files may be used without restrictions if Log4j’s native auto-configuration is applied. Note: Spring Boot actually enforces this property even for the classpath and files either intentionally or, more likely, unintentionally. -- 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
