Лучшие практики Groovy Shell Sandboxing

Я пытаюсь настроить песочницу Groovy Shell, которая может выполнять ненадежный код. Эти ненадежные коды предоставляются конечными пользователями (разработчиками) в виде конфигураций поведения, например как определить, имеет ли человек высокий собственный капитал. Так что они действительно являются частью основной программы. Мне нужно убедиться, что я не уязвим для плохого кода [например, бесконечный цикл] / hacks.

Я понимаю, что здесь играют роль две вещи:

  1. Виртуальная машина Java, обеспечивающая среду выполнения.
  2. Groovy Shell, который интерпретирует и выполняет код.

Существуют ли передовые методы изолирования Groovy Shell в песочнице?

Спасибо


person Charles Chan    schedule 05.02.2021    source источник
comment
Вы имеете в виду, что где-то в базе данных или файле conf пользователь вводит def isHighNetWorth(...) { ... }, и вы хотите прочитать это из db / conf и выполнить?   -  person BahmanM    schedule 09.02.2021


Ответы (2)


В итоге я создал файл политики. Что-то вроде этого:

grant codeBase "file:/your jar file" {
  permission java.security.AllPermissions;
}

grant codeBase "file:/groovy/shell" {
}

grant codeBase "file:/groovy/script" {
}

Когда Groovy выполняется в интерпретируемом режиме, codeBase имеет значение file:/groovy/shell или file:/groovy/script. Вы можете предоставить определенные разрешения для любого контекста. Эти разрешения (или их отсутствие) не зависят от того, что вы даете своей основной программе.

Помимо файла политики, есть еще много других соображений.

  1. Что вы вкладываете в контекст оценки? Если вы поставите стороннюю библиотеку, у них может даже не быть правильной проверки разрешений.

  2. Для некоторых системных вызовов, например System.out.println(), также нет проверки прав доступа. Так что, возможно, вам также понадобится средство проверки исходного кода (Дженкинс это делает).

  3. Чтобы ограничить использование ЦП, вам может потребоваться запустить сценарий Groovy в отдельном потоке.

  4. Вы, вероятно, захотите также ограничить возможности Groovy-скрипта import. Этого можно добиться с помощью Groovy ImportCustomizer.

Я написал статью: Secure Groovy Script Execution in Sandbox, чтобы обобщить мои выводы. Надеюсь, это поможет и другим.

person Charles Chan    schedule 11.03.2021

Было бы полезно немного больше контекста, но с учетом того, что вы описали:

Я настоятельно рекомендую запускать Groovyshell внутри контейнера - по одному контейнеру на пользователя / экземпляр.

Вы можете жестко контролировать доступ к диску, а также установить ограничение на использование ЦП и памяти контейнера.

А если вы хотите пойти на крайние меры, вы можете легко запустить каждый контейнер в отдельной сети без других узлов и доступа к Интернету.

При этом плохой код будет ограничен уязвимостями докеров, которые могут быть использованы из программы JVM.

person BahmanM    schedule 05.02.2021
comment
Спасибо за ответ. Я отредактировал вопрос, чтобы дать немного больше контекста: ... Эти ненадежные коды предоставляются конечными пользователями (разработчиками) в виде конфигураций поведения, например как определить, имеет ли человек высокий собственный капитал. Итак, они действительно являются частью основной программы ... У вас есть возможность запустить GroovyShell внутри контейнера. Однако даже в этом случае я бы не хотел, чтобы контейнер был скомпрометирован. - person Charles Chan; 06.02.2021