[
https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626730#comment-17626730
]
Henri Biestro edited comment on JEXL-381 at 10/31/22 6:11 PM:
--------------------------------------------------------------
[~ggregory], 'Permeability' was intended as 'how much' of the host platform
(application, server/service, JVM, OS, file-system) is accessible by JEXL; this
is indeed implemented by permissions so my bad for misnaming the intent,
permissibility is certainly a better word.
I don't understand your proposal in functional terms: how would the usability
level enum be used for and what would it bring? Would it be more than an
homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom'
configurations in our components? Couldn't it be done through a convention,
having a per-component enum at the top-level with the same name for each
component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?)
When and how to use these/this enum would be very specific anyway per project.
They would always be a required argument in some configuration method to
describe the permissivity of any Commons instance / singleton component but not
the sole one.
In JEXL's case, the basic method would be implemented through
factory/static-getters to instantiate/retrieve permissions. But this still
makes JEXL-381 a valid case as is; I would create another JIRA to use this new
tbd component when it is released.
was (Author: henrib):
'Permeability' was intended as 'how much' of the host platform (application,
server/service, JVM, OS, file-system) is accessible by JEXL; this is indeed
implemented by permissions so my bad for misnaming the intent, permissibility
is certainly a better word.
I don't understand your proposal in functional terms: how would the usability
level enum be used for and what would it bring? Would it be more than an
homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom'
configurations in our components? Couldn't it be done through a convention,
having a per-component enum at the top-level with the same name for each
component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?)
When and how to use these/this enum would be very specific anyway per project.
They would always be a required argument in some configuration method to
describe the permissivity of any Commons instance / singleton component but not
the sole one.
In JEXL's case, the basic method would be implemented through
factory/static-getters to instantiate/retrieve permissions. But this still
makes JEXL-381 a valid case as is; I would create another JIRA to use this new
tbd component when it is released.
> 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)
