Эта страница переведена с помощью Cloud Translation API.

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

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

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

Все потоки должны быть помещены в песочницу

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

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

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

Если вы не будете осторожны, то легко унаследовать множество зависимостей и побочных эффектов (дополнительные системные вызовы, доступ к файлам или даже сетевые подключения), которые усложняют работу в «песочнице» (отслеживание всех побочных эффектов) и делают ее менее безопасной (поскольку системный вызов и файловый политика шире). Некоторые параметры компиляции могут помочь уменьшить такие проблемы:

Статически скомпилируйте двоичный файл Sandboxee, чтобы избежать динамического связывания, которое использует множество системных вызовов ( open / openat , mmap и т. д.).
Поскольку Bazel добавляет pie по умолчанию, но static с ней несовместима, рассмотрите возможность использования флага функций, чтобы принудительно отключить ее с помощью следующих параметров в правилах cc_binary :
```
linkstatic = 1,
features = [
    "fully_static_link",  # link libc statically
    "-pie",
],
```

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

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

Это неудачный выбор, поскольку компилятор не поддерживает статические PIE (исполняемые файлы, независимые от позиции). PIE реализуется посредством того, что двоичный файл является динамическим объектом, а динамический загрузчик отображает его в случайном месте перед выполнением. Затем, поскольку куча традиционно размещается со случайным смещением после базового адреса двоичного файла (и расширяется с помощью системного вызова brk), это означает, что для статических двоичных файлов энтропия ASLR кучи равна только этому смещению, поскольку PIE отсутствует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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