Вопросы Теги

Как “заключить в тюрьму” процесс, не будучи корнем?

Примечание: "Мне установили владельца сценария, поскольку корень" ничего не делает; даже если у Вас есть setuid набор битов, он все еще не работает

Принятие Вы на самом деле запускаете скрипт как корень, однако, можно использовать sudo. su прежде всего, для переключения пользователей, в то время как sudo для выполнения команд как другие пользователи. -u флаг позволяет Вам указать который пользователь выполнить команду как:

sudo -u hudson command

26
12.03.2011, 15:08
5 ответов

Более подобный Qs с большим количеством ответов, стоящих внимания:

Примечание: Некоторые ответы там указывают на определенные решения, еще не упомянутые здесь.

На самом деле существует довольно много инструментов заключения в тюрьму с другой реализацией, но многие из них любой не безопасны дизайном (как fakeroot, LD_PRELOAD- базирующийся), или не завершенный (как fakeroot-ng, ptrace- базирующийся), или потребовал бы корня (chroot, или plash упомянутый в fakechroot предупреждение маркировки).

Это просто примеры; я думал о списке их всех бок о бок, с признаком этих 2 функций ("может доверяться?", "требует, чтобы корень настроил?"), возможно, при внедрениях виртуализации Уровня операционной системы.

В целом ответы там касаются полного описанного диапазона возможностей и еще больше:

виртуальные машины/ОС

расширение ядра (как SELinux)

  • (упомянутый в комментариях здесь),

chroot

Находящиеся в Chroot помощники (который однако должен быть корнем setUID, потому что chroot требует корня; или возможно chroot мог работать в изолированном пространстве имен - посмотрите ниже):

[для сообщения немного больше о них!]

Известные находящиеся в chroot инструменты изоляции:

  • мясорубка с hsh-run и hsh-shell команды. (Мясорубка была разработана для создания программного обеспечения безопасным и повторяемым способом.)
  • schroot упоминается в другом ответе
  • ...

ptrace

Другое защищенное решение для изоляции (помимо a seccomp- базирующийся один), был бы полный syscall-перехват через ptrace, как объяснено в странице справочника для fakeroot-ng:

В отличие от предыдущих реализаций, fakeroot-ng использует технологию, которая не оставляет прослеженный процесс никаким выбором относительно того, будет ли это использовать "сервисы" fakeroot-ng или нет. Компиляция программы статически, непосредственно вызов ядра и управление, собственное адресное пространство является всеми методами, которые могут тривиально использоваться для обхода LD_PRELOAD базирующееся управление процессом, и не относятся к fakeroot-ng. Теоретически, возможно прессовать fakeroot-ng таким способом как, чтобы иметь полный контроль над прослеженным процессом.

В то время как это теоретически возможно, это не было сделано. Fakeroot-ng действительно принимает бесспорный, "приятно вел себя" предположения о процессе, прослеживаемом, и процесс, которые повреждают те предположения, может, если не полностью выходят затем, по крайней мере, обходят часть "поддельной" среды, наложенной на него fakeroot-ng. По сути, Вас сильно предостерегают от использования fakeroot-ng как средства обеспечения безопасности. Отчеты об ошибках, которые утверждают, что процесс может deliberatly (в противоположность inadvertly) Escape, фальсифицируют корневое-ng's управление ‐, будет или закрыт как "не ошибка" или отмечен как низкий приоритет.

Возможно, что эта политика заново продумалась в будущем. В настоящее время, однако, Вас предупредили.

Однако, поскольку можно считать его, fakeroot-ng самостоятельно не разработан с этой целью.

(BTW, интересно, почему они приняли решение использовать seccomp- основанный подход для Хрома, а не a ptrace- базирующийся...)

Из инструментов, не упомянутых выше, я отметил Geordi мной, потому что мне понравилось это, программа управления записана в Haskell.

Известные находящиеся в ptrace инструменты изоляции:

seccomp

Один известный способ достигнуть изоляции через seccomp, играющий в песочнице подход, используемый в Google Chromium. Но этот подход предполагает, что Вы пишете помощнику, который обработал бы некоторых (позволенные) "прерванного" доступа к файлу и другого syscalls; и также, конечно, прилагают усилие, чтобы "прервать" syscalls и перенаправить их помощнику (возможно, это даже означало бы такую вещь как замена прерванного syscalls в коде управляемого процесса; таким образом это не звучит, чтобы быть довольно простым; если Вам интересно, необходимо считать детали, а не просто мой ответ).

Более связанная информация (из Википедии):

(Последний объект, кажется, интересен, если Вы ищете генерала seccomp- основанное решение за пределами Хрома. Существует также сообщение в блоге, которое стоит считать от автора "seccomp-медсестры": SECCOMP как решение для Игры в песочнице?.)

Иллюстрация этого подхода из проекта "seccomp-медсестры":

                      enter image description here

"Гибкое" seccomp возможное в будущем Linux?

Там раньше появлялся в 2009 также предложения для исправления ядра Linux так, чтобы было больше гибкости к seccomp режим - так, чтобы "многой из акробатики, в которой мы в настоящее время нуждаемся, можно было избежать". ("Акробатика" относится к сложностям записи помощника, который должен выполнить многих возможно невинный syscalls от имени заключенного в тюрьму процесса и замены возможно невинным syscalls в заключенном в тюрьму процессе.) Статья LWN записала в эту точку:

Одно предложение, которое вышло, состояло в том, чтобы добавить новый "режим" к seccomp. API был разработан с идеей, что различные приложения могли бы иметь различные требования к защите; это включает значение "режима", которое указывает ограничения, которые должны быть помещены на месте. Только исходный режим когда-либо реализовывался, но другие могут, конечно, быть добавлены. Создание нового режима, который позволил процессу инициирования указывать, какие системные вызовы будут позволены, сделало бы средство более полезным для ситуаций как песочница Chrome.

Adam Langley (также Google) отправил патч, который делает просто это. Новый "режим 2" реализации принимают битовую маску, описывающую, какие системные вызовы доступны. Если один из тех является prctl (), то поигравший в песочнице код может далее ограничить свои собственные системные вызовы (но он не может восстановить доступ к системным вызовам, которые были отклонены). Все сказали, это похоже на разумное решение, которое могло сделать жизнь легче для разработчиков песочницы.

Тем не менее этот код никогда не может объединяться, потому что обсуждение с тех пор шло дальше к другим возможностям.

Этот "гибкий seccomp" приблизил бы возможности Linux к обеспечению желаемой функции в ОС без потребности записать помощникам, которые усложнили.

(Сообщение в блоге с в основном тем же содержанием как этот ответ: http://geofft.mit.edu/blog/sipb/33.)

пространства имен (unshare)

Изоляция через пространства имен (unshare- основанные решения) - не упомянутый здесь - например, не совместно используя точки монтирования (объединенный с FUSE?) могла, возможно, быть часть рабочего решения для Вас желающий ограничить доступы к файловой системе Ваших недоверяемых процессов.

Больше на пространствах имен, теперь, когда их реализация была завершена (этот метод изоляции также известен под nme "Контейнеры Linux" или "LXC", не так ли?..):

"Одна из полных целей пространств имен состоит в том, чтобы поддерживать реализацию контейнеров, инструмента для легкой виртуализации (а также другие цели)".

Даже возможно создать новое пользовательское пространство имен, так, чтобы "процесс мог иметь нормальный непривилегированный идентификатор пользователя вне пользовательского пространства имен, одновременно имея идентификатор пользователя 0 внутренней части пространство имен. Это означает, что процесс имеет полные полномочия пользователя root для операций в пользовательском пространстве имен, но непривилегирован для операций вне пространства имен".

Чтобы реальные рабочие команды сделали это, см. ответы в:

и специальное программирование/компиляция пространства пользователя

Но хорошо, конечно, желаемые гарантии "тюрьмы" реализуемы путем программирования в пространстве пользователя (без дополнительной поддержки этой функции от ОС; возможно, вот почему эта функция не была включена во-первых в дизайне Ose); с более или менее сложностями.

Упомянутый ptrace- или seccomp- основанная игра в песочнице может рассматриваться как некоторые варианты реализации гарантий путем записи помощнику песочницы, который управлял бы другими процессами, которые будут рассматривать как "черные квадраты", произвольные программы Unix.

Другой подход мог быть должен использовать методы программирования, которые могут заботиться об эффектах, которые должны быть запрещены. (Это должны быть Вы, кто пишет программы затем; они больше не черные квадраты.) Для упоминания один, с помощью чистого языка программирования (который вынудил бы Вас к программе без побочных эффектов) как Haskell просто сделает все эффекты программы явными, таким образом, программист может легко удостовериться, что не будет никаких запрещенных эффектов.

Я предполагаю, там играют в песочнице средства, доступные для тех, которые программируют на некотором другом языке, например, Java.

На некоторые страницы, накапливающие информацию об этой теме, также указали в ответах там:

23
27.01.2020, 19:40
  • 1
    Беспочвенный GoboLinux мог бы быть опцией также... –  Tobias Kienzler 29.10.2013, 11:13
  • 2
    @tobias, Но Беспочвенный Gobolinux дает гарантию, что программа, записанная пользователем, не получит доступ к внешней среде?.. –  imz -- Ivan Zakharyaschev 30.10.2013, 11:57
  • 3
    Едва ли - я так или иначе являлся объектом неправильного представления, что оно также позволит становиться "локальным" пользователем root, который затем мог просто создать виртуальных пользователей для такого процесса - хотя могло бы быть возможно использовать chroot, но это, вероятно, все еще потребовало бы реальных полномочий пользователя root... –  Tobias Kienzler 30.10.2013, 12:02

Это - фундаментальное ограничение модели разрешения Unix: только корень может делегировать.

Вы не должны быть корнем для выполнения виртуальной машины (не верный для всех технологий VM), но это - тяжелое решение.

Непривилегированный режим Linux является относительно легким решением для виртуализации Linux на Linux. Дело не в этом легкий настроить; необходимо будет заполнить корневой раздел (в каталоге), по крайней мере, с минимумом, должен был загрузиться (несколько файлов в /etc, /sbin/init и его зависимости, программа входа в систему, оболочка и утилиты).

8
27.01.2020, 19:40

Я предполагаю, что у Вас может быть некоторая удача с LD_PRELOAD для прерывания доступа к определенным файлам но это могло бы быть действительно хитро.

1
27.01.2020, 19:40

подстановка команд в (t) csh (которую вы, кажется, используете) раскрывается в двойных кавычках, как в оболочках типа Bourne.

Итак, в: 

alias search "find `pwd` -name "

Вы фактически делаете что-то вроде: 

alias search 'find /some/dir -name '

Где / some / dir был текущим каталогом на момент выполнения команды alias .

Здесь вы хотите: 

alias search 'find $cwd:q -name'

$ cwd автоматически устанавливается tcsh (как и $ PWD в современных версиях, например, в оболочках POSIX), поэтому вы можно использовать его вместо менее эффективного и менее надежного `pwd` .

Мы используем одинарные (строгие) кавычки, чтобы не раскрывать $ cwd внутри.

$ cwd: q - передать значение переменной как один аргумент, а не позволить ему подвергнуться разделению.

Также обратите внимание, что вам не нужен пробел после -name выше.

Если вы хотите использовать pwd (например, чтобы получить канонический (без символических ссылок) путь к текущему рабочему каталогу, как в некоторых реализациях pwd , таких как GNU) когда POSIXLY_CORRECT не находится в среде), вы должны использовать: 

alias search 'find "`pwd`" -name'

Хотя это не сработает, если путь к текущему каталогу содержит символы новой строки.

Обратите внимание, что вы не можете использовать sudo search , поскольку псевдонимы раскрываются только в позиции команды в (t) csh. В оболочках POSIX вы можете: 

alias sudo='sudo '

Сообщать оболочке, что слово, следующее за sudo , также должно подвергаться расширению псевдонима, но этот трюк не работает в (t) csh.

Эквивалент POSIX sh (или bash / zsh / ksh ...) будет иметь следующий вид: 

alias search='find "$PWD" -name'
-121) --- 57925-

Из полного списка я бы просто добавил:

  • fakeroot (из debian package maintener): он нацелен на создание пакета с «дружественными» инструментами. Это не полная изоляция, но она помогает создавать пакеты с разными пользователями, поддельными устройствами и другими специальными псевдо-файлами.

  • fakechroot (который использует fakeroot). В этой программе много ошибок. Например, "/ etc / hosts" жестко запрограммирован в glibc: вы не можете изменить его с помощью этого инструмента.

  • qemu: вам нужно скомпилировать ядро ​​linux, но результат очень быстрый, и это «фальшивая» (т.е. виртуальная) машина с настоящими привилегиями root. Вы можете собрать и смонтировать любой загрузочный образ.

0
27.01.2020, 19:40

Firejail — хороший инструмент для блокировки любого процесса, с root-доступом или без него, с множеством опций и очень гибкий:

1
27.01.2020, 19:40

Теги

Похожие вопросы