Как отключить создание сокетов для процесса Linux, для песочницы?

Question

Я рассматриваю несколько вариантов песочницы процесса Linux.Использование clone() с CLONE_NEWNET (и т. Д.) Является одним из вариантов.CLONE_NEWNET гарантирует, что песочница не сможет установить или принять реальные сетевые подключения.Но я бы хотел полностью отключить сокеты для этого процесса, даже bind() для любого порта на 0.0.0.0 и привязку к сокету Doman Unix (даже анонимному).Я хотел бы сделать это, чтобы процесс не использовал слишком много ресурсов ядра, связываясь с тысячами портов.Как мне это сделать?

В общем, меня интересуют многие подходы песочницы (то есть те, которые предоставляются ядром Linux, и те, которые применяются ptrace()), но в этом вопросе меня интересует толькоаспект создания сокетов в подходах «песочницы» (поэтому, если вы предлагаете подход «песочницы», пожалуйста, также объясните, как предотвратить создание сокетов с ним), и меня не интересуют подходы, которые требуют исправления ядра или которые включают загрузку модуля ядране входит в стандартный двоичный пакет ядра Ubuntu Lucid или влияет на каждый процесс в системе.

Answer 1

ptrace кажется наиболее очевидным инструментом, но кроме этого…

util-linux [-ng] имеет команду unshare, которая использует ядро ​​clone / unshare интерфейсы.Если вы запускаете новый процесс через unshare -n (или clone(CLONE_NEWNET)), все создаваемые им сетевые сокеты находятся в другом пространстве имен.Это не решает проблему с ресурсом ядра, но делает песочницу для процесса.

Ядро Linux также поддерживает seccomp , режим, введенный с prctl(PR_SET_SECCOMP, 1), который предотвращает процесс (ну, потокдействительно) от вызова любых системных вызовов, кроме read, write, exit и sigreturn.Это довольно эффективная песочница, но ее трудно использовать с неизмененным кодом.

Вы можете определить домен SELinux, который запрещает socket / bind / и т.д.вызовы и выполнить динамический переход в этот тип.Это (очевидно) требует системы с активно применяемой политикой SELinux.(Возможно, подобные вещи возможны с AppArmor и TOMOYO, но я не очень знаком с любым из них.)

Answer 2

Взгляните на systrace - не ограничиваясь сокетами, а генератором / исполнителем общей политики syscall.Цитата:

Порт GNU / Linux завершен, и исправление ядра активно поддерживается Мариусом Эриксеном. Может быть запущен без изменений в ядре с помощью бэкэнда ptrace.

Disclamer - я никогда не пробовал в Linux.

Answer 3

Если ваша основная цель - ограничить число сокетов, открываемых каким-либо неопасным процессом P, примененным к доброкачественным входам, тогда setrlimit(RLIMIT_NOFILE, ...) будет делать примерно то, что вы хотите.

Однако, если предполагается, что P скорее злонамеренный, чем доброкачественный, или если вы ищете надежную уверенность в том, как P будет вести себя перед лицом потенциально вредоносных входных данных, то вам, вероятно, не повезло:В лучшем случае с помощью инструментов, доступных сегодня, вы можете создать полосу препятствий для злоумышленников.

(С другой стороны, если для вас работает полоса препятствий, вы можете получить более полезные идеи, заглянув сюда по адресу sandboxing.org или отправив свои вопросы дружественномулюди на sandboxing-talk@lists.sandboxing.org.)

Answer 4

Вас может заинтересовать песочница " sydbox " или библиотека " pinktrace ":

http://www.diigo.com/user/wierzowiecki/sydbox

Answer 5

Попробуйте seccomp (см. Справочную страницу prctl), он может ограничить ваш процесс только доступом к сокетам, которые оставались открытыми во время вызова prctl.