Running under a SecurityManager

["Piotr P. Karwasz" <pi...@gmail.com>]

Hello,

As noticed by Boris Unckel in LOG4J2-3579[1], there are some issues
when running Log4j2 under a SecurityManager, both from the
`ServiceLoader` and `PropertiesUtil` perspective.

From the `PropertiesUtil` perspective:

 * version 2.17.2 (cr. [2]) ignored all property sources that caused
an `AccessControllerException` (actually it probably ignored all
property sources from the classloader that caused the exception). This
behavior was introduced as a fix to LOG4J2-2266 [3].
 * the `ServiceLoaderUtil` I backported from `master` to 2.18.0
catches `ServiceLoaderException`s on a per-property source basis, but
it does not catch `AccessControllerException`s which can cause global
failures, as the one described by Boris.

I am wondering what is the best course of action in this case:

1. We can keep silently ignoring all exceptions thrown by the
`ServiceLoader` and the iterators it produces,
2. We can introduce some `AccessController#doPrivileged` calls in the
right places (cf. the PRs [4] and [5] by Boris).

I would prefer the second solution, but it requires adding security
checks to all the available property sources. The environment and
system properties sources are protected by internal Java security
checks, but the `log4j2.component.properties` and Spring property
sources are available for everyone to read. Some malicious code could
for example call
`PropertiesUtil.getProperty("log4j2.keyStorePassword")`.

What do you think?

Piotr

[1] https://issues.apache.org/jira/browse/LOG4J2-3579
[2] https://github.com/apache/logging-log4j2/blob/c33646f61850619c756797122f4fc4c53f7013f1/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L437
[3] https://issues.apache.org/jira/browse/LOG4J2-2266
[4] https://github.com/apache/logging-log4j2/pull/1006
[5] https://github.com/apache/logging-log4j2/pull/1007

Re: Running under a SecurityManager

[Gary Gregory <ga...@gmail.com>]

Side note: The SecurityManager will eventually go away, which might not
matter for us for a long time!
See https://openjdk.org/jeps/411

Gary

On Sun, Aug 21, 2022 at 8:12 AM Piotr P. Karwasz <pi...@gmail.com>
wrote:

> Hello,
>
> As noticed by Boris Unckel in LOG4J2-3579[1], there are some issues
> when running Log4j2 under a SecurityManager, both from the
> `ServiceLoader` and `PropertiesUtil` perspective.
>
> From the `PropertiesUtil` perspective:
>
>  * version 2.17.2 (cr. [2]) ignored all property sources that caused
> an `AccessControllerException` (actually it probably ignored all
> property sources from the classloader that caused the exception). This
> behavior was introduced as a fix to LOG4J2-2266 [3].
>  * the `ServiceLoaderUtil` I backported from `master` to 2.18.0
> catches `ServiceLoaderException`s on a per-property source basis, but
> it does not catch `AccessControllerException`s which can cause global
> failures, as the one described by Boris.
>
> I am wondering what is the best course of action in this case:
>
> 1. We can keep silently ignoring all exceptions thrown by the
> `ServiceLoader` and the iterators it produces,
> 2. We can introduce some `AccessController#doPrivileged` calls in the
> right places (cf. the PRs [4] and [5] by Boris).
>
> I would prefer the second solution, but it requires adding security
> checks to all the available property sources. The environment and
> system properties sources are protected by internal Java security
> checks, but the `log4j2.component.properties` and Spring property
> sources are available for everyone to read. Some malicious code could
> for example call
> `PropertiesUtil.getProperty("log4j2.keyStorePassword")`.
>
> What do you think?
>
> Piotr
>
> [1] https://issues.apache.org/jira/browse/LOG4J2-3579
> [2]
> https://github.com/apache/logging-log4j2/blob/c33646f61850619c756797122f4fc4c53f7013f1/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L437
> [3] https://issues.apache.org/jira/browse/LOG4J2-2266
> [4] https://github.com/apache/logging-log4j2/pull/1006
> [5] https://github.com/apache/logging-log4j2/pull/1007
>