Можно ли использовать нити?
Да, в Sandbox2 поддерживаются потоки.
Все потоки должны быть изолированы в песочнице.
В силу особенностей работы Linux, политика seccomp-bpf применяется только к текущему потоку: это означает, что политика не применяется к другим существующим потокам, но будущие потоки унаследуют её.
- Если вы используете Sandbox2 в первом режиме , где песочница включена до вызова
execve(), все потоки унаследуют политику, и проблем не возникнет. Это предпочтительный режим песочницы. - Если вы используете второй режим , в котором исполнитель имеет
set_enable_sandbox_before_exec(false), а объект Sandboxee сообщает исполнителю, когда он хочет перейти в песочницу, с помощьюSandboxMeHere(), убедитесь, что фильтр применяется ко всем потокам. В противном случае существует риск выхода за пределы песочницы: вредоносный код может переместиться из изолированного потока в неизолированный.
Как мне следует скомпилировать Sandboxee?
По сравнению со статически скомпилированным исполняемым файлом, компиляция изолированной среды в динамически скомпилированный исполняемый файл приведет к значительному увеличению количества системных вызовов (например, open / openat , mmap и т. д.), которые необходимо включить в список разрешенных. Все эти дополнительные системные вызовы необходимы из-за вызова динамического компоновщика во время выполнения для загрузки разделяемых библиотек.
Однако, если рассматривать статически связанные песочницы: хотя количество разрешенных системных вызовов уменьшается, это также влечет за собой проблемы с безопасностью; энтропия кучи ASLR снижается (с 30 бит до 8 бит), что упрощает использование эксплойтов.
Эта дилемма, по сути, сводится к следующему:
- Динамический режим : хорошее резервирование памяти в куче, потенциально сложнее добиться первоначального выполнения кода, но за счет менее эффективной политики песочницы, потенциально легче выйти из нее.
- Статический режим : плохая ASLR-система для кучи, потенциально упрощает выполнение начального кода, но обеспечивает более эффективную политику песочницы, однако потенциально сложнее из нее выйти.
Исторически сложилось так, что статически скомпилированные бинарные файлы не поддерживали позиционно-независимый код ( pie ). Кроме того, Bazel добавил pie по умолчанию. Для того чтобы иметь возможность определить жесткий фильтр системных вызовов, необходимо было переопределить значение по умолчанию в Bazel.
Компиляторы за прошедшие годы значительно улучшились и теперь поддерживают опцию static-pie . С этой опцией компилятору дается указание генерировать позиционно-независимый код, но по сравнению с pie это теперь включает в себя и все статически связанные библиотеки. С точки зрения безопасности, static-pie по-прежнему уменьшает энтропию ASLR (с 30 бит до 14 бит), но это улучшение по сравнению с предыдущей ситуацией без pie .
Поскольку Bazel по умолчанию добавляет pie , а статический библиотеку с ним несовместима, рассмотрите возможность использования флага параметров компоновщика для передачи флага -static-pie правилу cc_binary и переопределения значения по умолчанию:
linkstatic = 1,
linkopts=["-static-pie"],
В качестве примера использования этих опций посмотрите статический пример сборки : файл static_bin.cc статически связан с static-pie , что позволяет установить очень строгую политику системных вызовов. Это также хорошо подходит для изоляции сторонних бинарных файлов.
Можно ли изолировать 32-битные x86-файлы в песочнице?
Sandbox2 может изолировать только ту же архитектуру, с которой он был скомпилирован.
Кроме того, из Sandbox2 была удалена поддержка 32-битных архитектур x86. Если вы попытаетесь использовать 64-битный исполнитель x86 для изоляции 32-битного исполняемого файла x86 или 64-битного исполняемого файла x86, выполняющего 32-битные системные вызовы (через int 0x80), в обоих случаях возникнет нарушение песочницы, которое можно определить по архитектурной метке [X86-32].
Причина такого поведения заключается в том, что номера системных вызовов различаются в зависимости от архитектуры, и поскольку политика системных вызовов заложена в архитектуре исполнителя, было бы опасно разрешать использование другой архитектуры для песочницы. Действительно, это может привести к разрешению, казалось бы, безобидного системного вызова, который на самом деле может привести к тому, что другой, более опасный системный вызов откроет доступ к песочнице.
Существуют ли какие-либо ограничения на количество песочниц, которые может запросить процесс-исполнитель?
Для каждого экземпляра Sandboxee (нового процесса, запущенного из форк-сервера) создается новый поток — в этом и заключается ограничение.
Может ли исполнитель запросить создание более чем одной песочницы?
Нет. Существует отношение 1:1 – экземпляр Executor хранит PID объекта Sandboxee, управляет экземпляром Comms по отношению к экземпляру Sandbox и т. д.
Почему в файле forkserver.cc появляется сообщение «Функция не реализована»?
Sandbox2 поддерживает работу только на относительно новых ядрах. В настоящее время мы используем ядро версии 3.19, хотя в будущем это может измениться. Причина в том, что мы используем относительно новые функции ядра, включая пространства имен пользователей и seccomp с флагом TSYNC.
Если вы используете систему в продакшене, проблем возникнуть не должно, поскольку почти весь парк устройств работает на достаточно новом ядре. Если у вас возникнут какие-либо проблемы, пожалуйста, свяжитесь с нами.
Если вы используете Debian или Ubuntu, обновление ядра выполняется очень просто:
sudo apt-get install linux-image-<RECENT_VERSION>