Безопасность scala времени выполнения

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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