禁止导入语句和java.*字符串可以阻止对标准java库的访问吗？

假设我想允许人们在我的服务器上运行简单的控制台java程序，而不能访问文件系统、网络或其他IO，除非通过我自己的高度受限的API。但是，我不想深入到操作系统级的限制，所以为了当前的讨论，我想考虑代码级的消毒方法。 因此，假设我尝试实现以下限制。我将禁止所有“import”语句，除了那些显式列出的语句（比如允许“import SanitizedSystemIO.”，而不允许“import java.io.”），并且我将禁止代码中任何地方的字符串“java.*”。因此，通过这种方式，用户可以从SantizedSystemIO编写引用文件类的代码，但不能引用java.io.File。这样，用户被迫使用我的净化包装器API，而我自己的框架代码（将与用户代码一起编译和运行，例如为了提供IO功能）可以访问所有常规java API

这种方法有效吗？或者有没有办法破解它以访问标准JavaAPI

ETA：好的，首先，它当然应该是java.*字符串而不是system.*。我认为在C#中，基本上

第二，好的，人们说，“使用安全管理器”或“使用类加载器”方法。但是，如果代码分析方法有什么问题的话，那又是什么呢？在我看来，它的一个好处是非常简单——我们不需要在SecurityManager中找出所有需要检查和清理的内容，而是只允许一个功能的小白名单，并阻止所有其他内容。在实现方面，对于对java知之甚少的人来说，这是一个微不足道的练习

---

重申我最初的问题，那么这能被黑客攻击吗？是否存在允许访问底层api的java语言构造，尽管存在此类代码限制？

您需要检查

SecurityManager

。许多JVM类都会调用它，在它们执行工作之前检查它们是否具有所需的权限。

您可以实现自己的

站在你的立场上，我宁愿在自定义的

类加载器中运行加载的应用程序

也许我弄错了，但如果他想通过自己的函数允许对IO的有限访问，
SecurityManager
是否也会阻止这些？使用定制的
类加载器
，他可以提供他的
净化系统
，同时拒绝加载他不希望人们加载的东西

但是，检查代码中的字符串绝对不是一个好办法。
这篇文章提到了您的一些目标：）+1，使用自定义的
SecurityManager
，他可以检查堆栈跟踪并允许在请求来自他自己的库时访问IO，但这是一个同样有效的选项。@Jeffrey:啊，我明白了。我没有想到检查堆栈跟踪。但这不是一个昂贵的手术吗？自定义
ClassLoader
应该不会产生运行时成本。这相当昂贵，但是
check
方法并不经常被调用。您的答案很有趣（我以前不知道类加载器的内容），但我确实希望得到关于源代码清理方法的答案。是否可以被黑客攻击，如果可以，如何进行。源代码清理比适当的安全策略更容易出错。您可能会意外地留下漏洞（例如使用反射按名称加载类，使用
“ja”+“va.”
避免检测）。