Groovy Shell 沙盒最佳实践

如何解决Groovy Shell 沙盒最佳实践

我正在尝试设置一个可以执行不受信任的代码的 Groovy Shell 沙箱。这些不受信任的代码由最终用户（开发人员）作为行为配置提供，例如如何判断一个人是否高净值。因此，它们确实是主程序的一部分。我需要确保我不会受到任何不良代码的影响 [例如无限循环]/hacks。

我知道这里有两件事在起作用：

1. 提供运行时的 Java 虚拟机。
2. 解释和执行代码的 Groovy Shell。

是否有对 Groovy Shell 进行沙盒处理的最佳实践？

谢谢

解决方法

我最终创建了一个策略文件。像这样：

grant codeBase "file:/your jar file" {
  permission java.security.AllPermissions;
}

grant codeBase "file:/groovy/shell" {
}

grant codeBase "file:/groovy/script" {
}

当 Groovy 在解释模式下执行时，codeBase 要么是 file:/groovy/shell，要么是 file:/groovy/script。您可以为任一上下文授予特定权限。这些权限（或缺乏权限）与您授予主程序的权限无关。

除了策略文件，还有很多其他的考虑。

1. 您将什么放入评估环境中？如果你放置了一个 3rd 方库，他们甚至可能没有适当的权限检查。

2. 一些系统调用，比如 System.out.println() 也没有权限检查。所以，也许您还需要一个源代码检查器（Jenkins 做到了）。

3. 要限制 CPU，您可能需要在单独的线程中运行 Groovy 脚本。

4. 您可能还想限制 Groovy 脚本可以import 的内容。这可以通过 Groovy ImportCustomizer 实现。

我写了一篇文章：Secure Groovy Script Execution in a Sandbox 来总结我的发现。我希望它也能帮助其他人。

,

多一点上下文会有所帮助，但考虑到您的描述：

我强烈建议在容器内运行 groovyshell - 每个用户/实例一个容器。

您可以严格控制磁盘访问，还可以为容器的 CPU 和内存使用设置上限。

如果你想走极端，你可以轻松地在自己的网络中运行每个容器，没有其他节点，也没有互联网访问。

这样，不良代码将完全限于可从 JVM 程序中利用的 docker 漏洞。