jvz commented on issue #2100:
URL:
https://github.com/apache/logging-log4j2/issues/2100#issuecomment-1858589557
Some initial thoughts about this:
* Configuration files or configuration code have the ability to execute
arbitrary code by using custom plugins; as such, configurations must be
controlled by the programmer, not arbitrary users.
* Log message parameters are not evaluated for any sort of template strings
like `{}`; template strings are limited to the non-parameter message argument.
As such, log message parameters are not treated specially (such as with a
prepared statement in SQL). When structure-preserving encoding is desired for
things besides the log message as a whole, the `Message` API should be used for
logging structured data rather than strings.
* Unstructured layouts shouldn't be used if any user-controlled data can be
logged through them; this largely includes logging exceptions if said
exceptions can contain user input (which is a common use case for exceptions).
* Code signing and verification is only performed at the artifact level
(i.e., our jars, zips, and tarballs); we do not rely on jar signing to validate
plugins or extensions (unlike, say, the Java cryptography APIs which require
signed jars typically).
* Given the equivalence to the halting problem, we cannot generically
support any form of log masking for sensitive data. While external plugins may
support limited forms of masking (e.g., for credit card numbers or similar
easily identifiable byte patterns), it is up to the programmer to explicitly
mark sensitive data for masking.
* While the project goes to great lengths to minimize performance overhead
along with options for minimizing latency or maximizing throughput, we cannot
guarantee absolute availability of the system when using synchronous logging.
If your application is writing log data faster than it can store it to disk,
synchronous logging will affect the availability of your application. Using
asynchronous logging can help to an extent here, though we do not support back
pressure signals (this might be a patches welcome area; not sure if we need to
define this in the security model).
* We do not support running in a Java `SecurityManager`; this API is being
removed from Java anyways.
* Configurations can read system properties, environment variables,
arguments to the main program, and any other data sources made available via
`StrLookup` plugins (which includes some HTTP-related data if you use the
`WebLookup` plugin).
Then we have some bits that are specific to various systems:
* When using JNDI for configuration files (as in a JavaEE/JakartaEE
application server) or for use with dependency injection of shared server
resources (such as JMS connection pools, JDBC connection pools, etc.), only the
`java` scheme is supported. We do not support nor recommend use of other JNDI
providers that interact with potentially untrusted remote data sources due to
the weak security model of JNDI itself. Yes, that means we don't support LDAP,
RMI, DNS, or any other `Context` providers.
* When using an unstructured layout, we cannot guarantee that user input
cannot interfere with the output of the formatted log message. Within the
pattern layout plugin specifically, we do offer various encoding methods to
help address this for different use cases (such as encoding or escaping new
lines or other special characters used in various formats), but they're all
opt-in.
* When using a structured layout such as JsonTemplateLayout, XML, etc., log
message input data is encoded appropriately to the target layout (e.g., a log
message containing XML data will be properly escaped inside an XML layout).
* Advanced methods of handling configuration (such as a refresh period for
the config file, JMX remote management, or other remote methods for updating a
config) must be protected by the programmer behind some form of authentication
and authorization; it is beyond the scope of this library to hand wave away
your identity solution or file permissions.
* Use of string lookup plugins that can reference user-controlled data
should not be used with unstructured layouts
* Use of PatternLayout is more of a developer convenience than a
production-quality layout that can be reliably parsed by log collectors or
other derivative systems. In that sense, any inline JSON, whitespace, XML,
etc., are not treated differently as pattern layouts are fairly arbitrary. When
a reliable format is needed for parsing the output of logs, a structured layout
should be used.
* Any form of encryption or signatures used on log data directly from the
library must use a proper key management system. Use of cryptography anywhere
requires a properly designed key management system, and any plugins or
extensions that offer to do so using a single static key (symmetric or
asymmetric) are likely broken beyond repair.
* When using compression, if logs can contain user input, then the
compressed log output must not be viewable directly or indirectly by the user
if said logs are supposed to be private. This relates to the [CRIME
attack](https://en.wikipedia.org/wiki/CRIME) which affects older versions of
TLS.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
