Безопасность Scala Runtime - PullRequest
       18

Безопасность Scala Runtime

15 голосов
/ 15 февраля 2010

Я разработчик Robocode движок. Мы хотели бы сделать Robocode Многоязычный и Скала, кажется, хороший матч. У нас есть плагин Scala прототип здесь .

Проблема: Поскольку пользователи являются творческими программистами, они могут попытаться выиграть битву различные пути. Также роботы загружаются из онлайн-базы данных. где любой мог загрузить один. Таким образом, разрыв в безопасности может привести к безопасности дыра в компьютере пользователя. Роботы, написанные на Java, работают в ограниченная песочница. Почти все запрещено [сеть, графический интерфейс, диск (ограниченный), потоки (ограниченный), загрузчики классов и рефлексия]. Песочница похожа на апплет браузера. Мы используем SecurityManager, на заказ ClassLoader для каждого робота, и т. Д. *

Существует два способа размещения среды выполнения Scala в Robocode:

1) загрузить его вместе с роботом внутри песочницы. Довольно безопасно для нас, предпочтительное решение. Но это повредит способности времени выполнения Scala, потому что среда выполнения использует отражение. Может генерировать классы во время выполнения? Использовать потоки для внутренней очистки? Доступ к JVM / внутренним органам? (Я бы не хотел ограничивать способности языка)

2) использовать среду выполнения Scala в качестве доверенного кода, нестандартно, защита включена тот же уровень, что и JDK. Видимость (вредоносная) робот. Насколько безопасны API среды выполнения Scala? У методов у них есть безопасность охранники? Есть ли безопасный режим? Есть ли синглтон в Scala Runtime, чем можно злоупотреблять для общения между роботами? Любой параллелизм / пул потоков / обмен сообщениями, который может имитировать потоки? (Есть ли аудит безопасности для среды выполнения Scala?)

3) Что-то среднее, некоторые классы времени выполнения и некоторые вне. Какие классы / пакеты должны быть видны роботу / которые являются только частной реализацией? (это, кажется, будущее решение)

Вопрос: Можно ли перечислить и изолировать части времени выполнения, которые должны выполняться в доверенная сфера от остальных? Конкретные пакеты и классы? Или лучшая идея?

Я ищу конкретный ответ, который приведет к безопасному решению. Случайные мысли приветствуются, но не награждаются. В scala email group продолжается обсуждение. Конкретного ответа пока нет.

Ответы [ 2 ]

3 голосов
/ 15 февраля 2010

Я думаю, что # 1 - ваша лучшая ставка, и даже это движущаяся цель. Как указано в списке рассылки, структурные типы используют отражение. Я не думаю, что структурные типы распространены в стандартной библиотеке, но я не думаю, что кто-то отслеживает, где они находятся.

Всегда существует вероятность того, что есть другие функции, использующие отражение за кулисами. Например, некоторое время в ветке 2.8 некоторые функции массива использовали отражение. Я думаю, что это изменилось после бенчмаркинга, но всегда есть вероятность, что есть какая-то проблема, когда кто-то говорит: «Ага! Я буду использовать рефлексию, чтобы решить эту проблему».

Стандартная библиотека Scala заполнена синглетонами. Большинство из них являются неизменяемыми, но я знаю, что объект Scheduler в библиотеке акторов может быть использован для связи, потому что он по сути является прокси для фактического планировщика, поэтому вы можете подключить к нему свой собственный планировщик.

В настоящее время я не думаю, что Scala требует использования пользовательского загрузчика классов, и все его классы создаются во время компиляции, а не во время выполнения, но, опять же, это, вероятно, движущаяся цель. Scala генерирует много файлов классов, и всегда говорят о том, чтобы заставить их генерировать некоторые из них во время выполнения, когда они необходимы, а не во время компиляции.

Итак, вкратце, я не думаю, что можно (в рамках разумных ограничений усилий) перечислять и выделять фрагменты Scala, которым можно (и нужно) доверять.

0 голосов
/ 25 февраля 2010

Как вы упомянули в других реализациях языка J *, в которых все могут использовать отражения, это будет запретом для всех этих языков, если отражение не является частью игры. Я полагаю, что проблема JVM в том, чтобы не иметь возможности разделить сферу API отражения, так что вы могли бы сортировать «песочницу» ту часть кода, которая может быть отражена внутри.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...