Безопасность scala времени выполнения
Я - разработчик механизма Robocode. Мы хотели бы сделать Robocode многоязычным, и Scala, кажется, хорошее соответствие. У нас есть прототип плагина Scala здесь.
Проблема: Поскольку пользователи являются творческими программистами, они могут попытаться выиграть сражение различные пути. Также роботы загружаются с базы данных онлайн, где любой мог загрузить тот. Таким образом, разрыв в безопасности может привести к дыре в системе безопасности в пользовательский компьютер. Роботы, записанные в Java, работают в ограниченной песочнице. Почти все запрещается [сеть, GUI, (ограниченный) диск, распараллеливает (ограниченный), classloaders и отражение]. Песочница подобна апплету браузера. Мы используем SecurityManager, пользовательский ClassLoder на робот, и т.д...
Существует два пути, как разместить время выполнения Scala в Robocode:
1) загрузите его вместе с роботом в песочнице. Довольно безопасный для нас, предпочтительного решения. Но это повредит способности ко времени выполнения Scala, потому что время выполнения использует отражение. Возможно, генерирует классы во времени выполнения? Использовать потоки, чтобы сделать некоторую внутреннюю очистку? Доступ к JVM/внутренностям? (Я не хотел бы ограничивать способности языка),
2) используйте время выполнения Scala в качестве доверяемого кода, вне поля, безопасности на том же уровне как JDK. Видимость к (злонамеренному) роботу. Действительно ли API времени выполнения Scala безопасны? Методы у них есть охранники? Есть ли какой-либо безопасный режим? Есть ли во времени выполнения Scala какой-либо одиночный элемент, которым можно было злоупотребить для передачи между роботами? Какой-либо concurency/threadpool/messaging, который мог моделировать потоки? (Есть ли какая-либо проверка защиты для времени выполнения Scala?)
3) Что-то промежуточное, некоторые классы времени выполнения в и некоторых. Какие классы/пакеты должны быть видимы к роботу/которому, просто частная реализация? (это, кажется, будущее решение),
Вопрос: действительно ли возможно перечислить и изолировать части времени выполнения, которое должно работать в доверяемом объеме от остальных? Определенные пакеты и классы? Или лучшая идея?
Я ищу определенный ответ, который приведет к безопасному решению. Случайное приветствие мыслей, но не награжденный. Существует продолжающееся обсуждение в scala почтовой группе. Никакой определенный ответ все же.
2 ответа
Думаю, №1 - ваш лучший выбор, и даже это движущаяся цель. Как упоминалось в списке рассылки, структурные типы используют отражение. Я не думаю, что структурные типы распространены в стандартной библиотеке, но я не думаю, что кто-то отслеживает, где они находятся.
Также всегда есть вероятность, что есть другие функции, использующие отражение за кадром. Например, некоторое время в ветке 2.8 некоторые функции массива использовали отражение. Я думаю, что это было изменено после тестирования, но всегда есть вероятность, что есть какая-то проблема, когда кто-то сказал: «Ага! Я воспользуюсь отражением, чтобы решить эту проблему».
Стандартная библиотека Scala заполнена синглтонами. Большинство из них неизменяемы, но я знаю, что объект Scheduler в библиотеке акторов может быть использован для связи, потому что он, по сути, является прокси для реального планировщика, поэтому вы можете подключить к нему свой собственный планировщик.
В настоящее время я не думаю, что Scala требует использования специального загрузчика классов, и все его классы создаются во время компиляции, а не во время выполнения, но опять же, это, вероятно, движущаяся цель. Scala генерирует множество файлов классов, и всегда говорят о том, чтобы заставить его генерировать некоторые из них во время выполнения, когда они необходимы, а не во время компиляции.
Короче говоря, я не думаю, что возможно (при разумных ограничениях усилий) перечислить и изолировать те части Scala, которым можно (и нужно) доверять.
Как вы упомянули другие реализации языка J *, все из которых могут использовать отражения, это будет запретом для всех этих языков, если отражение не является частью игры. Я думаю, проблема JVM состоит в том, чтобы не иметь способа разделить область действия API отражения, чтобы вы могли сортировать из «песочницы» часть кода, которая может быть отражена внутри.