Больше похожих вопросов с большим количеством ответов, заслуживающих внимания:
ПРИМЕЧАНИЕ: некоторые ответы там указывают на конкретные решения, еще не упомянутые здесь.
На самом деле, существует довольно много инструментов для джейлинга с разной реализацией, но многие из них либо не защищены по конструкции (например fakeroot, на LD_PRELOADоснове), либо не завершены (например fakeroot-ng, на ptraceоснове), либо требуют root ( chrootили plashупоминаются в fakechroot). предупреждающая табличка ).
Это всего лишь примеры; Я подумал о том, чтобы перечислить их все рядом, с указанием этих двух функций («можно ли доверять?», «Требуется настроить root?»), Возможно, в реализациях виртуализации на уровне операционной системы .
В общем, ответы там охватывают весь описанный диапазон возможностей и даже больше:
виртуальные машины / ОС
расширение ядра (например, SELinux)
- (упоминается в комментариях здесь),
корневой
Помощники на основе Chroot (которые, тем не менее, должны быть root-ID setUID, потому что chrootтребуется root; или, возможно, chrootмогут работать в изолированном пространстве имен - см. Ниже):
[рассказать немного больше о них!]
Известные инструменты изоляции на основе chroot:
- hasher со своими
hsh-runи hsh-shellкомандами. ( Hasher был разработан для создания программного обеспечения безопасным и воспроизводимым способом.)
- Schroot упоминается в другом ответе
- ...
ptrace
Другое решение изоляции надежной (помимо более seccompоснованных один ) будет полный системный вызов-перехват через ptrace, как описано в разделе страницы руководства для fakeroot-ng:
В отличие от предыдущих реализаций, fakeroot-ng использует технологию, которая не оставляет отслеживаемому процессу никакого выбора относительно того, будет ли он использовать «сервисы» fakeroot-ng или нет. Статическая компиляция программы, прямой вызов ядра и манипулирование собственным адресным пространством - все это методы, которые можно тривиально использовать для обхода процесса управления на основе LD_PRELOAD и не применяются к fakeroot-ng. Теоретически возможно сформировать fakeroot-ng таким образом, чтобы иметь полный контроль над отслеживаемым процессом.
Хотя это теоретически возможно, это не было сделано. Fakeroot-ng допускает определенные «хорошо ведущие себя» предположения о отслеживаемом процессе, и процесс, который нарушает эти предположения, может, если не полностью избежать, то, по крайней мере, обойти некоторую «поддельную» среду, навязанную ему fakeroot- нг. Поэтому вам настоятельно рекомендуется не использовать fakeroot-ng в качестве инструмента безопасности. В сообщениях об ошибках утверждается, что процесс может намеренно (в противоположность непреднамеренному) избежать контроля fake-root-ng, либо будет закрыт как «не ошибка», либо помечен как имеющий низкий приоритет.
Вполне возможно, что эта политика будет переосмыслена в будущем. В настоящее время, однако, вы были предупреждены.
Тем не менее, как вы можете прочитать, fakeroot-ngсам по себе не предназначен для этой цели.
(Кстати, мне интересно, почему они решили использовать seccompподход на основе хрома, а не на ptraceоснове ...)
Из инструментов, не упомянутых выше, я отметил Geordi для себя, потому что мне понравилось, что управляющая программа написана на Haskell.
Известные инструменты изоляции на основе ptrace:
Seccomp
Один из известных способов обеспечить изоляцию - использование изолированной среды seccomp, используемой в Google Chromium . Но этот подход предполагает, что вы пишете помощника, который будет обрабатывать некоторые (разрешенные) из «перехваченного» доступа к файлу и других системных вызовов; а также, конечно, приложить усилия, чтобы «перехватить» системные вызовы и перенаправить их к помощнику (возможно, это будет означать даже такую вещь, как замена перехваченных системных вызовов в коде контролируемого процесса; так что это не звучит быть довольно простым; если вам интересно, вам лучше прочитать подробности, а не только мой ответ).
Более связанная информация (из Википедии):
(Последний пункт кажется интересным, если кто-то ищет общее seccompрешение за пределами Chromium. Есть также запись в блоге, которую стоит прочитать от автора "seccomp-nurse": SECCOMP как решение для песочницы?. )
Иллюстрация этого подхода из проекта "seccomp-nurse" :
«Гибкий» seccomp возможен в будущем Linux?
Раньше в 2009 году появлялись также предложения по исправлению ядра Linux, чтобы обеспечить большую гибкость seccompрежима - чтобы «можно было избежать многих акробатических действий, которые нам нужны в настоящее время». («Акробатика» относится к сложностям написания помощника, который должен выполнить множество возможно невинных системных вызовов от имени заключенного в тюрьму процесса и замены возможно невинных системных вызовов в заключенном в тюрьму процессе.) Статья LWN написала на этот счет:
Одно предложение, которое появилось, состояло в том, чтобы добавить новый "режим" к seccomp. API был разработан с учетом того, что разные приложения могут иметь разные требования безопасности; он включает в себя значение «mode», которое определяет ограничения, которые должны быть установлены. Только оригинальный режим когда-либо был реализован, но другие, безусловно, могут быть добавлены. Создание нового режима, позволяющего инициирующему процессу указывать, какие системные вызовы будут разрешены, сделает это средство более полезным для таких ситуаций, как песочница Chrome.
Адам Лэнгли (также из Google) опубликовал патч, который делает именно это. Новая реализация «режима 2» принимает битовую маску, описывающую, какие системные вызовы доступны. Если одним из них является prctl (), то изолированный код может дополнительно ограничить свои собственные системные вызовы (но он не может восстановить доступ к системным вызовам, которые были отклонены). В общем и целом, это похоже на разумное решение, которое может облегчить жизнь разработчикам песочницы.
Тем не менее, этот код никогда не может быть объединен, потому что обсуждение с тех пор перешло к другим возможностям.
Этот «гибкий seccomp» приблизил бы возможности Linux к предоставлению желаемой функции в ОС, без необходимости писать сложные помощники.
(Публикация в блоге в основном с тем же содержанием, что и этот ответ: http://geofft.mit.edu/blog/sipb/33 .)
пространства имен ( unshare)
Изоляция с помощью пространств имен ( unshareоснованных на решениях ), не упомянутых здесь, например, неиспользование точек монтирования (в сочетании с FUSE?) Может быть частью рабочего решения, если вы хотите ограничить доступ к файловой системе ваших ненадежных процессов.
Подробнее о пространствах имен, теперь, когда их реализация завершена (этот метод изоляции также известен под nme «Контейнеры Linux», или «LXC» , не так ли? ..):
«Одной из общих целей пространств имен является поддержка реализации контейнеров, инструмента для облегченной виртуализации (а также других целей)» .
Можно даже создать новое пространство имен пользователя, чтобы «процесс мог иметь обычный непривилегированный идентификатор пользователя вне пространства имен пользователя, и в то же время иметь идентификатор пользователя 0 внутри пространства имен. Это означает, что процесс имеет полные права root для операций внутри пространства имен пользователя, но непривилегирован для операций вне пространства имен ".
Для реальных рабочих команд, чтобы сделать это, см. Ответы в:
и специальное программирование / компиляция пространства пользователя
Но, конечно же, желаемые гарантии «тюрьмы» реализуются путем программирования в пользовательском пространстве ( без дополнительной поддержки этой функции со стороны ОС ; возможно, именно поэтому эта функция не была включена в первую очередь при проектировании ОС ); с более или менее осложнениями.
Упомянутая ptrace- или seccompоснованная песочницу можно рассматривать как некоторые варианты осуществления гарантий в письменном виде песочницы-помощник , который будет контролировать ваши другие процессы, которые будут рассматриваться в качестве «черных ящиков», произвольных программ Unix.
Другой подход может заключаться в использовании методов программирования, которые могут заботиться о последствиях, которые должны быть запрещены. (Должно быть, вы пишете программы тогда; они больше не являются черными ящиками.) Чтобы упомянуть одно, использование чистого языка программирования (который заставил бы вас программировать без побочных эффектов), такого как Haskell , просто сделает все эффекты Программа явно, так что программист может легко убедиться, что не будет никаких запрещенных эффектов.
Я предполагаю, что для этих программ доступны средства песочницы на каком-то другом языке, например, Java.
На некоторые страницы, накапливающие информацию по этой теме, также указывались в ответах: