Scala运行时的安全性
我是 Robocode 引擎的开发人员。我们想要制作 Robocode 多语言和 Scala 似乎是很好的搭配。我们有 Scala 插件原型 。
问题： 因为用户是有创造力的程序员，他们可能会试图赢得战斗 不同的方式。机器人也是从在线数据库下载的 任何人都可以上传一个。所以安全上的差距可能会导致安全 侵入用户计算机。用Java编写的机器人运行在 受限沙箱。几乎一切都被禁止 [网络、GUI、 磁盘（有限）、线程（有限）、类加载器和反射]。这 沙箱类似于浏览器小程序。我们使用SecurityManager，自定义 每个机器人的类加载器，etc ...
在 Robocode 中托管 Scala 运行时有两种方法：
1）将其与沙箱内的机器人一起加载。对我们来说相当安全， 首选解决方案。但它会损害 Scala 运行时能力，因为运行时使用反射。也许在运行时生成类？使用线程进行一些内部清理？访问 JVM/内部结构 ? （我不想限制语言的能力）
2）使用 Scala 运行时作为可信代码，开箱即用，安全性高 与JDK同一级别。可见性（恶意） 机器人。 Scala 运行时 API 安全吗？采取他们有安全性的方法 警卫？有安全模式吗？ Scala运行时是否有单例， 哪些可能被滥用于机器人之间的通信？任何可以模拟线程的并发/线程池/消息传递？ （Scala 运行时有安全审计吗？）
3）介于两者之间，运行时的某些类进出。哪些类/包必须对机器人可见/哪些只是私有实现？ （这似乎是未来的解决方案）
问题： 是否可以枚举和隔离必须运行的运行时部分 其余的可信范围？ 具体的包和类？或者更好的主意？
我正在寻找具体的答案，这将导致安全的解决方案。欢迎随意的想法，但不予奖励。 scala 电子邮件组正在进行讨论。目前还没有具体答案。
I'm developer of Robocode engine. We would like to make Robocode
multilingual and Scala seems to be good match. We have Scala plugin prototype here.
The problem:
Because users are creative programmers, they may try to win battle
different ways. As well robots are downloaded from online database
where anyone could upload one. So gap in security may lead to security
hole into users computer. Robots written in Java are running in
restricted sandbox. Almost everything is prohibited [network, GUI,
disk (limited), threads (limited), classloaders and reflection]. The
sandbox is similar to browser applet. We use SecurityManager, custom
ClassLoader per robot, etc ...
There are two ways how to host Scala runtime in Robocode:
1) load it together with robot inside of sandbox. Pretty safe for us,
preferred solution. But it will damage Scala runtime abilities because runtime uses reflection. Maybe generates classes at runtime ? Use threads to do some internal cleanup ? Access to JVM/internals ? (I would not like to limit abilities of language)
2) use Scala runtime as trusted code, outside the box, security on
same level as JDK. Visibility to (malicious)
robot. Are the Scala runtime APIs safe ? Do methods they have security
guards ? Is there any safe mode ? Is there any singleton in Scala runtime,
which could be abused to communicate between robots ? Any concurency/threadpool/messaging which could simulate threads ? (Is there any security audit for Scala runtime?)
3) Something in between, some classes of runtime in and some out. Which classes/packages must be visible to robot/which are just private implementation ? (this seems to be future solution)
The question:
Is it possible to enumerate and isolate the parts of runtime which must run in
trusted scope from the rest ? Specific packages and classes ? Or better idea ?
I'm looking for specific answer, which will lead to secure solution. Random thoughts welcome, but not awarded. There is ongoing discussion at scala email group. No specific answer yet.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为#1 是你最好的选择，即使这是一个不断变化的目标。正如邮件列表中提到的，结构类型使用反射。我认为结构类型在标准库中并不常见，但我认为没有人跟踪它们的位置。
总有可能有其他功能在幕后使用反射。例如，在 2.8 分支中有一段时间，一些数组功能使用了反射。我认为在基准测试之后这已经改变了，但是总是有可能出现一些问题，有人说“啊哈！我将使用反射来解决这个问题。”
Scala 标准库充满了单例。它们中的大多数都是不可变的，但我知道参与者库中的 Scheduler 对象可能会被滥用于通信，因为它本质上是实际调度程序的代理，因此您可以将自己的自定义调度程序插入其中。
目前，我认为 Scala 不需要使用自定义类加载器，并且它的所有类都是在编译时而不是运行时生成的，但话又说回来，这可能是一个移动目标。 Scala 生成大量类文件，并且总是有人谈论让它在需要时而不是在编译时在运行时生成其中一些文件。
因此，简而言之，我认为不可能（在合理的努力限制内）枚举和隔离可以（并且应该）信任的 Scala 部分。
I think #1 is your best bet and even that is a moving target. As brought up on the mailing list, structural types use reflection. I don't think structural types are common in the standard library, but I don't think anyone keeps track of where they are.
There's also always the possibility that there are other features using reflection behind the scenes. For example, for a while in the 2.8 branch some array functionality was using reflection. I think that's been changed after benchmarking, but there's always the possibility that there's some problem where someone said "Aha! I will use reflection to solve this."
The Scala standard library is filled with singletons. Most of them are immutable, but I know that the Scheduler object in the actors library could be abused for communication because it is essentially a proxy for an actual scheduler so you can plug your own custom scheduler into it.
At this time I don't think Scala requires using a custom class loader and all of its classes are produced at compile time instead of runtime, but then again that's probably a moving target. Scala generates a lot of class files, and there is always talk of making it generate some of them at runtime when they are needed instead of at compile time.
So, in short, I do not think it's possible (within reasonable constraints on effort) to enumerate and isolate the pieces of Scala that can (and should) be trusted.
正如您提到的其他 J* 语言实现都可能使用反射，只要反射不是游戏的一部分，所有这些语言都会被禁止。
我想这将是 JVM 的问题，因为没有办法划分反射 API 的范围，这样您就可以将可以在其中反射的代码部分放入“沙箱”中。
As you mentioned other J* language implementations which all may make use of reflections, it would be a ban for all those languages as long as reflection is not part of the game.
I guess that would be JVM's problem not to have a way to partition the scope of reflection API, such that you could sort of "sandbox" the part of code that could be reflected within.