Как fakeroot не является нарушением безопасности в Linux?

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

Пока что я могу понять, что fakeroot используется для передачи прав на файл, который должен быть root, когда он распакован / tar-файл. Мой вопрос, почему ты не можешь просто сделать это с Чоуном?

Обсуждение групп Google здесь указывает на то, что вам нужен fakeroot для компиляции ядра Debian (если вы хотите сделать это от непривилегированного пользователя). Мой комментарий таков: причина, по которой вам нужно быть пользователем root для компиляции, возможно, потому что права на чтение не были установлены для других пользователей. Если это так, не является ли это нарушением безопасности, что fakeroot допускает компиляцию (что означает, что gcc теперь может читать файл, который был для root)?

Этот ответ здесь описывает, что реальные системные вызовы выполняются с использованием реального uid / gid пользователя , так что опять же помогает fakeroot?

Как fakeroot останавливает нежелательные повышения привилегий в Linux? Если fakeroot может заставить tar создать файл, который принадлежит root, почему бы не сделать что-то похожее с SUID?

Из того, что я собрал, fakeroot просто полезен, когда вы хотите изменить владельца любых файлов пакетов, которые вы создали для root. Но вы можете сделать это с помощью chown, так где мне не хватает понимания того, как предполагается использовать этот компонент?

Пока что я могу понять, что fakeroot используется для передачи прав на файл, который должен быть root, когда он распакован / tar-файл. Мой вопрос, почему ты не можешь просто сделать это с Чоуном?

Потому что вы не можете просто сделать это chown, по крайней мере, не как пользователь без полномочий root. (И если вы работаете от имени пользователя root, вам это не нужно fakeroot.) В этом весь смысл fakeroot: позволить программам, которые ожидаются от имени пользователя root, запускаться от имени обычного пользователя, в то же время делая вид, что операции, требующие root, успешны.

Обычно это используется при сборке пакета, так что процесс установки устанавливаемого пакета может продолжаться без ошибок (даже если он выполняется chown root:root, и install -o rootт. Д.). fakerootзапоминает поддельное владение, которое он притворял, чтобы передать файлы, поэтому последующие операции, проверяющие владение, видят это вместо реального; это позволяет при последующих tarзапусках, например, сохранять файлы как принадлежащие пользователю root.

Как fakeroot останавливает нежелательные повышения привилегий в Linux? Если fakeroot может заставить tar создать файл, который принадлежит root, почему бы не сделать что-то похожее с SUID?

fakerootничего не обманывает tar, он сохраняет изменения, которые хочет внести сборка, не позволяя этим изменениям влиять на систему, в которой находится сборка. Вам не нужно fakerootсоздавать тарбол, содержащий файл, принадлежащий root и suid; если у вас есть бинарный файл evilbinary, работающий tar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryот имени обычного пользователя создаст тарбол, содержащий evilbinaryroot и suid. Однако вы не сможете извлечь этот tarball и сохранить эти разрешения, если вы не сделаете это от имени root: здесь повышение привилегий не происходит. fakerootэто привилегия де- инструмент эскалации: он позволяет запускать сборку как обычный пользователь, сохраняя при этом эффекты, которые сборка имела бы, если бы она была запущена от имени пользователя root, что позволяет воспроизводить эти эффекты позже. Применение эффектов «по-настоящему» всегда требует корневых привилегий; fakerootне предоставляет какой-либо способ их приобретения.

Чтобы понять использование fakerootболее подробно, рассмотрим, что типичная сборка дистрибутива включает в себя следующие операции (среди многих других):

• установить файлы, принадлежащие пользователю root
• ...
• заархивируйте эти файлы, все еще принадлежащие пользователю root, чтобы при извлечении они принадлежали пользователю root

Первая часть явно терпит неудачу, если вы не root. Однако при работе под fakerootобычным пользователем процесс становится

• установить файлы, принадлежащие пользователю root - это не удается, но fakerootделает вид, что оно успешно, и запоминает изменение владельца
• ...
• архивировать эти файлы, все еще принадлежащие пользователю root - когда tar(или какой-либо другой архиватор) спрашивает систему о том, кто является владельцем файла, fakerootизменяет ответ в соответствии с владельцем, записанным ранее

Таким образом, вы можете запустить сборку пакета, не будучи root, и получить те же результаты, которые вы получите, если бы вы действительно работали как root. Использовать fakerootбезопаснее: система по-прежнему не может делать ничего, что не может сделать ваш пользователь, поэтому неэффективный процесс установки не может повредить вашу систему (кроме касания ваших файлов).

В Debian были улучшены инструменты сборки, чтобы больше не требовать этого, и вы можете собирать пакеты без нихfakeroot . Это поддерживается dpkgнепосредственно с помощью Rules-Requires-Rootдирективы (см. rootless-builds.txt).

Чтобы понять назначение fakerootи аспекты безопасности запуска от имени пользователя root или нет, это может помочь рассмотреть назначение упаковки. Когда вы устанавливаете часть программного обеспечения из источника, для использования в масштабе всей системы, вы делаете следующее:

1. собрать программное обеспечение (что можно сделать без прав)
2. установить программное обеспечение (которое должно быть выполнено от имени пользователя root или, по крайней мере, от имени пользователя, которому разрешено писать в соответствующие места системы)

Когда вы упаковываете часть программного обеспечения, вы откладываете вторую часть; но чтобы сделать это успешно, вам все равно нужно «установить» программное обеспечение в пакет, а не в систему. Поэтому, когда вы упаковываете программное обеспечение, процесс становится:

1. собрать программное обеспечение (без особых привилегий)
2. делать вид, что установил программное обеспечение (опять же без особых привилегий)
3. захватить установку программного обеспечения как пакет (то же самое)
4. сделать пакет доступным (то же самое)

Теперь пользователь завершает процесс, устанавливая пакет, что необходимо сделать от имени пользователя root (или опять же, пользователя с соответствующими правами для записи в соответствующие места). Именно здесь реализуется отложенный привилегированный процесс, и это единственная часть процесса, которая требует специальных привилегий.

fakeroot помогает с шагами 2 и 3, описанными выше, позволяя нам запускать процессы установки программного обеспечения и фиксировать их поведение, не работая от имени пользователя root.

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

Если вы хотите создать структуру каталогов, которая содержит владельца и права доступа, которые не могут быть установлены вашим пользователем, полезно, чтобы вы затем использовали tar, zip или другой пакет.

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

Это не недостаток безопасности, потому что он не разрешает доступ или что-либо, что вы не можете сделать без него. Он работает без привилегий. Все это доза составляет перехватывать звонки на chown, chmodи т.д. Это делает их отсутствие операций, за исключением того, что он записывает то , что случилось бы. Он также перехватывает вызовы statи т. Д., Поэтому он сообщает о разрешениях и владельце из собственной внутренней базы данных, как если бы были выполнены другие команды. Это полезно, потому что если вы затем заархивируете каталог, у него будут поддельные разрешения. Если вы затем распакуете как root, то разрешения станут реальностью.

Любые файлы, которые ранее не были доступны для чтения / записи, останутся недоступными для чтения / записи. Любые созданные специальные файлы (например, устройства) не будут иметь особых полномочий. Любой set-uid (другому пользователю), файлы не будут set-uid. Любое другое повышение привилегий не будет работать.

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

Здесь уже есть два хороших и очень подробных ответа, но я просто укажу, что вступительный абзац оригинальной fakeroot справочной страницы ¹ действительно объясняет это довольно четко и кратко:

fakeroot запускает команду в среде, в которой, как представляется, он имеет привилегии root для манипулирования файлами. Это полезно для того, чтобы позволить пользователям создавать архивы (tar, ar, .deb и т. Д.) С файлами в них с правами root / владельцем. Без fakeroot нужно было бы иметь права суперпользователя для создания составных файлов архивов с правильными разрешениями и владельцем, а затем упаковать их, иначе придется создавать архивы напрямую, без использования архиватора.

Fakeroot позволяет пользователю без полномочий root создавать архивы, содержащие файлы, принадлежащие пользователю root, что является критически важной частью создания и распространения двоичных пакетов программного обеспечения в Linux. Без fakerootэтого архивы пакетов должны были бы быть сгенерированы при работе в качестве фактического root, чтобы они содержали правильное владение файлом и разрешения. Это было бы угрозой безопасности. Построение и упаковка потенциально ненадежного программного обеспечения является огромной угрозой, если оно выполняется с правами root. Благодаря fakerootэтому непривилегированный пользователь с непривилегированными файлами все еще может создавать архивы, содержащие файлы с правами суперпользователя. ²

Но это не угроза безопасности, потому что ничто в архиве на самом деле не принадлежит root до тех пор, пока файлы не будут извлечены . И даже в этом случае файлы будут извлечены с сохраненными корневыми правами, только если это сделает привилегированный пользователь. На этом этапе - когда fakerootвспомогательный архив с «корневыми» файлами извлекается привилегированным пользователем - именно тогда «поддельный» корень наконец становится реальным. До этого момента никакие действительные привилегии суперпользователя никогда не получались и не игнорировались.

Примечания

1. Fakeroot породил некоторых конкурентов / имитаторов, которые будут маскироваться, как fakerootесли бы они были установлены, включая fakeroot-ngи pseudo. Но ИМХО ни на одной из страниц руководства «подражателя» не так ясно сказано, как правильно разобраться в этом вопросе. Палка с оригинальной, единственной fakerootОГ

2. Другие дистрибутивы / системы упаковки преодолевают это, просто не используя root-права в своих архивах пакетов. Например, в Fedora программное обеспечение может быть скомпилировано, установлено и упаковано непривилегированным пользователем без необходимости fakeroot. Все это делается в $HOME/rpmbuild/пространстве пользователя , и обычно привилегированные шаги, такие как, make installперенаправляются (через механизмы, подобные --prefixи DESTDIR) в $HOME/rpmbuild/BUILDROOT/иерархию, которая может рассматриваться как своего рода «поддельное пространство» (без фактического использования fakechroot).

   Но даже во время make installвсе выполняется как и принадлежит непривилегированному пользователю. Владельцы извлеченных файлов и разрешения будут установлены по умолчанию root,rootи 0644(или 0755для исполняемых файлов), если только они не будут переопределены в .specфайле определения пакета ( ); в этом случае они сохраняются как метаданные в конечном пакете. Поскольку никакие разрешения или владение фактически не применяются до процесса установки (привилегированного) пакета rpm, fakerootво время упаковки не требуется ни root, ни необходимость. Но fakerootна самом деле это просто другой путь к тому же результату.