(logging-site) branch main updated: separated log4net threat model (#4)

[fr...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

freeandnil pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/logging-site.git


The following commit(s) were added to refs/heads/main by this push:
     new 40ddf4dd separated log4net threat model (#4)
40ddf4dd is described below

commit 40ddf4dd629e81228063374e20510676b16b615e
Author: Jan Friedrich <43...@users.noreply.github.com>
AuthorDate: Wed Aug 28 10:39:09 2024 +0200

    separated log4net threat model (#4)
---
 _threat-model-common.adoc  |  4 ++-
 _threat-model-log4net.adoc | 61 ++++++++++++++++++++++++++++++++++++++++++++++
 security.adoc              |  2 ++
 3 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/_threat-model-common.adoc b/_threat-model-common.adoc
index 1e08f2f5..5698d334 100644
--- a/_threat-model-common.adoc
+++ b/_threat-model-common.adoc
@@ -33,7 +33,9 @@ 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.
-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.
+
+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.
 
diff --git a/_threat-model-log4net.adoc b/_threat-model-log4net.adoc
new file mode 100644
index 00000000..4bca1a06
--- /dev/null
+++ b/_threat-model-log4net.adoc
@@ -0,0 +1,61 @@
+////
+    Licensed to the Apache Software Foundation (ASF) under one or more
+    contributor license agreements.  See the NOTICE file distributed with
+    this work for additional information regarding copyright ownership.
+    The ASF licenses this file to You under the Apache License, Version 2.0
+    (the "License"); you may not use this file except in compliance with
+    the License.  You may obtain a copy of the License at
+
+         https://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing, software
+    distributed under the License is distributed on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+    See the License for the specific language governing permissions and
+    limitations under the License.
+////
+
+[#threat-log4net]
+=== Log4Net threat model
+
+Below we share the threat model specific to link:/log4net[log4net].
+
+[#threat-log4net-parametrized-logging]
+==== Parameterized logging
+
+When using a log message containing template parameters like `{0}`, only the format string is evaluated for parameters to be substituted.
+The message parameters themselves are not evaluated for parameters; they are only included in the format string corresponding to their template position.
+The conversion of message parameters into a string is done on-demand depending on the layout being used.
+When structure-preserving transformations of log data are required, a structured layout (e.g., `XmlLayout`) should be used.
+Format strings should be compile-time constants, and under no circumstances should format strings be built using user-controlled input data.
+
+[#threat-log4net-unstructured-logging]
+==== Unstructured logging
+
+When using an unstructured layout such as `PatternLayout`, no guarantees can be made about the output format.
+This layout is mainly useful for development purposes and should not be relied on in production applications.
+For example, if a log message contains new lines, these are not escaped or encoded.
+As such, when using unstructured layouts, no user-controlled input should be included in logs.
+It is strongly recommended that a structured layout (e.g., `XmlLayout`) is used instead for these situations.
+
+[#threat-log4net-structured-logging]
+==== Structured logging
+
+When using a structured layout (most layouts besides pattern layout), log messages are encoded according to various output formats.
+These safely encode the various fields included in a log message.
+For example, the `XmlLayout` can be used to output log messages in an XML structure where all log data is properly encoded into safely parseable XML.
+This is the recommended mode of operation for use with log parsing and log collection tools that rely on log files or arbitrary output streams.
+
+[#threat-log4net-log-masking]
+==== Log masking
+
+Log4Net, like any other generic logging library, cannot generically support log masking of sensitive data.
+While custom plugins may be developed to attempt to mask various regular expressions (such as a string that looks like a credit card number), the general problem of log masking is equivalent to the halting problem in computer science where sensitive data can always be obfuscated in such a way as to avoid detection by log masking.
+As such, it is the responsibility of the developer to properly demarcate sensitive data such that it can be consistently masked by log masking plugins.
+
+[#threat-log4net-availability]
+==== Availability
+
+Log4Net goes to great lengths to minimize performance overhead along with options for minimizing latency or maximizing throughput.
+However, we cannot guarantee availability of the application if the appenders cannot keep up with the logs being written.
+Logging can cause applications to block and wait for a log message to be written.
\ No newline at end of file
diff --git a/security.adoc b/security.adoc
index b0127485..cc36b7db 100644
--- a/security.adoc
+++ b/security.adoc
@@ -51,6 +51,8 @@ include::_threat-model-common.adoc[]
 
 include::_threat-model-log4j.adoc[]
 
+include::_threat-model-log4net.adoc[]
+
 [#policy]
 == Vulnerability handling policy