Security is a multi-faceted concern. You could use SecureASTCustomizer[1][2] to prohibit calls to classes which perform shell command execution. That would stop most casual users being able to make such calls. It wouldn't stop some forms of reflective invocation of those calls or an AST transform which re-injects such calls back into the code after the SecureASTCustomizer has done its checks. You can go further and inject additional checks to ensure such calls aren't made which is what the sandbox code you referenced does in the context of Jenkins. And it too has limitations (as mentioned by that project) but maybe quite sufficient for your purposes. You can also mix in normal JVM security manager behavior if/where appropriate.
Cheers, Paul. [1] https://docs.groovy-lang.org/latest/html/api/org/codehaus/groovy/control/customizers/SecureASTCustomizer.html [2] https://mrhaki.blogspot.com/2014/04/groovy-goodness-restricting-script.html On Fri, Jun 5, 2020 at 6:18 PM Francesco Chicchiriccò <ilgro...@apache.org> wrote: > Hi all, > at Syncope we enjoy the power and flexibility of Groovy to allow for > runtime definition of classes implementing existing Java interfaces; such > classes are then used to extend and customize the Syncope behavior. > > The code which creates the Groovy classes is [1]. > > What if we would like to *not* allow for shell command execution in such > classes? Would something like [2] be the right solution? > > TIA > Regards. > > [1] > https://github.com/apache/syncope/blob/2_1_X/core/spring/src/main/java/org/apache/syncope/core/spring/ImplementationManager.java#L187-L200 > [2] http://groovy-sandbox.kohsuke.org/ >
