Java中不受信任的Groovy脚本安全性

我们正试图在“企业”产品中提供可编写脚本的元素。我们希望使用groovy，但是我们很难保证非常基本的东西

例如，我们希望阻止客户简单地

Class.forName("my.company.internal.SecruityTools").runAsAwesome(...)

我们安装了一个安全管理器，其策略仅允许

accesDeclaredMembers

，并覆盖了

checkPackageAccess

方法，只允许白名单软件包。不幸的是，默认的类加载器链似乎只是绕过了这一点，并以任何方式加载该类

这似乎是一个相当常见/讨论过的问题，但我一生都找不到一个库，甚至找不到一篇关于如何在更大的应用程序上下文中锁定不受信任的脚本的好博客文章

---

有人这样做成功吗？我是否遗漏了一些相当明显的帖子/概念？是否已经有一个可靠的库用于此？可能

Groovy.tinFoilHatMode（true）

？

您看过使用吗。还有一个关于如何将它与groovy一起使用的教程：

请查看。您可以使用它来停止类似于

系统.exit（0）

或

新文件（“/etc/passwd”）

的操作，我们最终完成的是上述操作的组合，但真正的魔法酱是实现包装任何表达式（包括

this

，或隐式

this

）在访问检查中。

可能有帮助吗？答案指向，它提供了一种看似合理的机制来防止这类事情……如果我没有弄错的话，有相当多的动态语言功能可以防止任何类型的AST保护。类似对象的东西。（“ge”+t”+“ClassLoader”）“fo“+$rname或诸如此类的傻事。@Ambience您是否尝试过ig0774建议的程序？我不相信你能像你建议的那样用技巧来逃避他们，如果你能，这是应该尽快报告给Groovy团队的事情。我们已经在使用它来防止一些公开的攻击，但即使在那篇文章的评论中，也有人指出，您可以简单地使用方法迭代来获取方法指针并执行您想要的任何东西（我相信其他groovy foo超出了我的初步理解）。但我们会看看是否能找到一个很好的方法来锁定它。我觉得一个更干净的解决方案应该包括设置类加载器链，使其始终根据安全管理器或其他网关管理员检查类加载。您也可以看到我的回答是否有帮助。如果我错了，请纠正我，但这似乎隐式地围绕着编译的源代码，并且只是帮助缩小脚本的策略范围。我们的代码为评估线程中的所有源定义了一个非常严格的策略。因此，这将帮助我们“范围”我们的权限，但不会做任何神奇的事情，导致Class.forName权限开始被验证（我看不到这一点，只看groovy对它的内部引用）。当我有机会返回时，我将看一看这一点，谢谢！