Защита системы при использовании API интерпретатора Scala

Question

Я создал простой REPL бот для scala.

Он работает в среде Linux и обрабатывает записанный scala код в диалоговых окнах и дает результат:

Например

user| 1+1
bot | res0: Int = 2
user| res0 + 3
bot | res1: Int = 5
...

Я использовал для этой цели API интерпретатора scala .

Код, который обрабатывает данный string как код scala:

private val settings = new Settings
settings.processArgumentString(
    """
      |-deprecation
      |-feature
      |-Xfatal-warnings
      |-Xlint
      |-usejavacp
      |""".stripMargin)

def run(code: String, id: Long): (Result, String) = {
    stream.reset()
    try {
        val intp = intpMap.getOrElseUpdate(id, new IMain(settings, new PrintWriter(stream, true)))
        timedRun(maxWorkTime)(intp.interpret(code)) -> stream.toString
    } catch {
        case e: TimeoutException => (Error, s"Долго считать - иди в пень")
    }
}

НоВ следующем случае возникает проблема: что если пользователь попытается получить доступ к системным файлам?Например напишет строку:

scala.sys.process.stringToProcess("ls /").!!

бот даст доступ к системным файлам.Я также попробовал этот фрагмент кода в https://scastie.scala -lang.org / и получил доступ к системным файлам.Но я думаю, что они запускают REPL в Docker-контейнере, и с этим нет проблем.

Есть ли способы ограничить доступ экземпляра jvm, на котором работает мой бот, к системным файлам, или, может быть, я могу ограничить доступ к файлам в REPLКонфиги API?

В настоящее время я выполняю анализ заданной строки для подстрок 'scala.sys' или 'java.io', но думаю, что она ненадежна.

И есть ликакие-нибудь другие уязвимости в безопасности?

Answer 1

Насколько я могу судить, встроенное в JVM решение имеет вид SecurityManager.

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

Альтернативой, которая, на мой взгляд, будет более безопасной, будет запуск вашего REPL в качестве отдельного процесса без доступа на системном уровне - в основном создайте очень ограниченного пользователя, запустите в этом процессе вторую JVM и обменивайтесь данными через некоторый RPC - таким образомсама операционная система позаботится о том, чтобы остановить попытки всех злых пользователей.

Хотя, чтобы быть еще более безопасным, я бы совмещал оба варианта: запуск REPL в отдельном процессе с ограниченным доступом на уровне системы, а также SecurityManager.

Как вы заметили, Scastie решает эту проблему просто с помощью Docker - если вы настраиваете Docker для ограничения amoбез использования ЦП, памяти и дискового пространства на образ, и ничего от хоста к образу не подвергайте.

Тогда ваши «единственные» проблемы - это эксплойты, такие как распад / призрак.Но на этом этапе вам следует проконсультироваться с экспертом по безопасности, поскольку SO может быть слишком общим для этого.