[
https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626628#comment-17626628
]
Gary D. Gregory edited comment on JEXL-381 at 10/31/22 2:53 PM:
----------------------------------------------------------------
I'm not sure "permeability" is the best word to use here. I think you might
have meant "permissibility".
Just like for Commons Text and Commons Configuration, either by FUD or
hindsight, it feels like we need to do something, so propose we take a step
back and consider something more useful even if it broadens the scope of this
conversation. I would consider something like the list below which could be
built in a new component or added to Commons Configuration in a new Maven
module (which would make Configuration a multi-module Commons component)
A Commons component could be defined perhaps through an enum with a useability
level of:
* MINIMUM aliased to DEFAULT: A "secure" but minimally functional
configuration. This is the default configuration. This configuration cannot be
edited programmatically. Could this be a problem when the library is used in
more than one place? Needs further thought, probably not since we also have
USER.
* CUSTOM: A programmatically defined configuration. This configuration cannot
be edited after construction.
* USER: Defined from system properties, environment variables, and config
files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or
CUSTOM configuration to be edited through the means listed previously.
* ALL: The kitchen sink, caveat emptor.
Thoughts?
was (Author: garydgregory):
I'm not sure "permeability" is the best word to use here. I think you might
have meant "permissibility".
Just like for Commons Text and Commons Configuration, either by FUD or
hindsight, it feels like we need to do something, so propose we take a step
back and consider something more useful even if it broadens the scope of this
conversation. I would consider something like the list below which could be
built in a new component or added to Commons Configuration in a new Maven
module (which would make Configuration a multi-module Commons component)
A Commons component could be defined perhaps through an enum with a useability
level of:
* MINIMUM aliased to DEFAULT: A "secure" but minimally functional
configuration. This is the default configuration. This configuration cannot be
edited programmatically. Could this be a problem when the library is used in
more than one place? Needs further thought, probably not since we also have
USER.
* CUSTOM: A programmatically defined configuration. This configuration cannot
be edited after construction.
* USER: Defined from system properties, environment variables, and config
files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or
CUSTOM configuration to be edited.
* ALL: The kitchen sink, caveat emptor.
Thoughts?
> Change default JEXL configuration to a more security-friendly behaviour
> ------------------------------------------------------------------------
>
> Key: JEXL-381
> URL: https://issues.apache.org/jira/browse/JEXL-381
> Project: Commons JEXL
> Issue Type: Improvement
> Affects Versions: 3.2.1
> Reporter: Henri Biestro
> Assignee: Henri Biestro
> Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> JEXL's default builder allows accessing and calling any public method, field
> or constructor of any public class. This might not be desirable since a quick
> exploration of JEXL will quickly conclude the library allows arbitrary
> execution through commands (ProcessBuilder) or getting to the file-system
> through URL or File. This improvement goal is to change JEXL's permeability
> as an explicit option and user decision, not a default behaviour.
> HOW:
> By changing the current JexlBuilder to use a restricted set of permissions
> whilst instantiating the Uberspect, we can ensure a minimal useful set of
> classes can be accessed and only those by default. By removing access to
> almost all classes that interact with the JVM host and file-system, we ensure
> a default isolation that would significantly reduce the ability to use JEXL
> as an attack vector.
> CAVEAT:
> This change will likely break many scripts that were dependant upon the
> default permeability.
> [~ggregory], [~dmitri_blinov] your opinions are welcome :-)
> https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
