Часто задаваемые вопросы

Могу ли я использовать нити?

Да, потоки поддерживаются в Sandbox2.

Все потоки должны быть изолированы

Из-за особенностей работы Linux политика seccomp-bpf применяется только к текущему потоку: это означает, что политика не применяется к другим существующим потокам, но будущие потоки унаследуют политику:

  • Если вы используете Sandbox2 в первом режиме , где песочница включена до execve() , все потоки унаследуют политику, и проблем не возникнет. Это предпочтительный режим песочницы.
  • Если вы используете второй режим , в котором исполнитель устанавливает set_enable_sandbox_before_exec(false) , а Sandboxee сообщает исполнителю, когда он хочет быть изолированным с помощью SandboxMeHere() , убедитесь, что фильтр применяется ко всем потокам. В противном случае существует риск выхода за пределы песочницы: вредоносный код может мигрировать из изолированного потока в неизолированный.

Как мне скомпилировать Sandboxee?

По сравнению со статически скомпонованным исполняемым файлом, компиляция песочницы в динамически скомпонованный исполняемый файл приведёт к значительному увеличению числа системных вызовов (например, open / openat , mmap и т. д.), которые необходимо добавить в разрешённый список. Все эти дополнительные системные вызовы необходимы из-за вызова динамического компоновщика во время выполнения для загрузки общих библиотек.

Однако, если взглянуть на статически скомпонованные песочницы: хотя меньшее количество системных вызовов нужно вносить в разрешенный список, это также имеет последствия для безопасности; энтропия кучи ASLR уменьшается (с 30 бит до 8 бит), что упрощает эксплойты.

Это дилемма, которую по сути можно свести к следующему:

  • Динамический : хороший ASLR кучи, потенциально сложнее добиться начального выполнения кода, но за счет менее эффективной политики «песочницы» потенциально легче выйти.
  • Статический : плохая куча ASLR, потенциально проще добиться начального выполнения кода, но более эффективная политика «песочницы», из которой потенциально сложнее выйти.

Исторически статически скомпонованные двоичные файлы не поддерживали позиционно-независимый код ( pie ). Кроме того, Bazel добавил pie по умолчанию. Чтобы определить строгий фильтр системных вызовов, приходилось перезаписывать значение Bazel по умолчанию.

Компиляторы совершенствовались с годами и теперь поддерживают опцию static-pie . С этой опцией компилятору предписывается генерировать позиционно-независимый код, но, по сравнению с pie , теперь он также включает все статически скомпонованные библиотеки. С точки зрения безопасности, static-pie по-прежнему снижает энтропию ASLR (с 30 до 14 бит), но это улучшение по сравнению с предыдущей ситуацией без pie .

Поскольку Bazel добавляет pie по умолчанию, а static с ним несовместим, рассмотрите возможность использования флага параметров компоновщика для передачи флага компоновщика -static-pie правилу cc_binary и перезаписи значения по умолчанию:

  linkstatic = 1,
  linkopts=["-static-pie"],

Пример этих возможностей можно увидеть в статическом примере BUILD : static_bin.cc статически связан с static-pie , что позволяет реализовать очень строгую политику системных вызовов. Это также отлично подходит для изоляции сторонних исполняемых файлов в «песочнице».

Могу ли я изолировать 32-битные исполняемые файлы x86?

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

Кроме того, поддержка 32-битной архитектуры x86 удалена из Sandbox2. Если вы попытаетесь использовать 64-битный исполняющий модуль x86 для изоляции 32-битного двоичного файла x86 или 64-битный двоичный файл x86, выполняющий 32-битные системные вызовы (через int 0x80), в обоих случаях возникнет нарушение «песочницы», которое можно определить по метке архитектуры [X86-32].

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

Существуют ли ограничения на количество песочниц, которые может запросить процесс-исполнитель?

Для каждого экземпляра Sandboxee (новый процесс, порожденный forkserver) создается новый поток — вот в чем заключается ограничение.

Может ли Исполнитель запросить создание более одной Песочницы?

Нет. Существует отношение 1:1 — экземпляр Executor хранит PID Sandboxee, управляет экземпляром Comms для экземпляра Sandbox и т. д.

Почему я получаю сообщение «Функция не реализована» внутри forkserver.cc?

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

Если вы работаете в режиме prod, проблем возникнуть не должно, поскольку практически весь парк использует достаточно новое ядро. Если у вас возникнут какие-либо проблемы, пожалуйста, свяжитесь с нами.

Если вы работаете в Debian или Ubuntu, обновить ядро так же просто, как выполнить:

sudo apt-get install linux-image-<RECENT_VERSION>