Як фальшивка не є порушенням безпеки в Linux?


18

Прочитавши кілька приємних відповідей з цього питання , я все ще нечітко розумію, чому ви хочете зробити вигляд, що ви кореневий, не отримуючи жодної користі від того, що насправді є root.

Поки що я можу зібрати, це те, що фейк-корт використовується для надання права власності на файл, який повинен бути root, коли він розпаковується / tar'ed. Моє запитання: чому ти не можеш просто зробити це з чуном?

Google Groups обговорення тут вказує на те , що вам потрібно fakeroot скомпілювати ядро Debian (якщо ви хочете зробити це від непривилегированного користувача). Мій коментар полягає в тому, що для компіляції вам потрібно мати root, тому що дозволи на читання не встановлено для інших користувачів. Якщо так, чи не є порушенням безпеки, яке fakeroot дозволяє компілювати (а значить, тепер gcc може прочитати файл, котрий був для root)?

Ця відповідь тут описує, що фактичні системні дзвінки здійснюються з реальним uid / gid користувача , тож знову ж таки, де допомагає підроблена програма?

Як фальшивка зупиняє небажані ескалації привілеїв в Linux? Якщо fakeroot може підманути tar на створення файлу, який належав root, чому б не зробити щось подібне з SUID?

З того, що я зібрав, фальшивка просто корисна, коли ви хочете змінити власника будь-яких пакунків, створених на root. Але ви можете це зробити з чууном, тож де мені не вистачає розуміння того, як цей компонент передбачається використовувати?


1
Для компіляції ядра вам не потрібна підробка. Система побудови ядра не така божевільна. Пов'язана дискусія стосується створення пакета ядра Debian , в якому фактична збірка ядра - лише один крок.

@ WumpusQ.Wumbley Я виправлю це, а ви можете мені сказати, чому це так?
ng.newbie

Тому що фальшивка - справа Debian, а Linux - це більше, ніж Debian?

@ WumpusQ.Wumbley він повинен працювати на будь-якому дистрибутиві.
користувач253751

Відповіді:


33

Поки що я можу зібрати, це те, що фейк-корт використовується для надання права власності на файл, який повинен бути root, коли він розпаковується / tar'ed. Моє запитання: чому ти не можеш просто зробити це з чуном?

Тому що ви не можете просто зробити це з chown, принаймні, як не-root користувач. (І якщо ви працюєте як root, вам не потрібно fakeroot.) У цьому вся суть fakeroot: дозволити програмам, які розраховують на те, що виконуватиметься як root, як звичайний користувач, роблячи вигляд, що операції, що вимагають кореня, успішні.

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

Як фальшивка зупиняє небажані ескалації привілеїв в Linux? Якщо fakeroot може підманути tar на створення файлу, який належав root, чому б не зробити щось подібне з SUID?

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

Щоб зрозуміти використання fakerootбільш детально, врахуйте, що типова побудова розподілу включає в себе наступні операції (серед багатьох інших):

  • встановити файли, що належать 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. захоплення інсталяції програмного забезпечення як пакета (ditto)
  4. зробити пакет доступним (дітто)

Тепер користувач завершує процес, встановивши пакет, який потрібно зробити як root (або знову ж таки, користувач з відповідними привілеями записати у відповідні місця). Тут реалізується відкладений привілейований процес, і це єдина частина процесу, яка потребує спеціальних привілеїв.

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


1
@ ng.newbie Якщо ви хочете альтернативного пояснення: мені цілком можливо використовувати шестигранний редактор, щоб вручну побудувати файл tar, що містить файли, що належать root або з будь-якими іншими можливими дозволами. Адже лише деяка інформація, згрупована, зрештою, вона не має ніякої сили, поки файл фактично не існує в системі.
mbrig

@ ng.newbie Ви знімаєте це з фальшивим кодом або без підробки?
користувач253751

2
@ ng.newbie, крім того, якщо ви хочете створити тарбол з бінарним файлом suid-root для шкідливих цілей, ви можете зробити це на іншій машині як справжній корінь, а потім скопіюйте його в ціль. Тут немає необхідності в підробці. fakeroot - це лише інструмент, який допомагає створити tar-файл, він усуває необхідність використання tar --mode --ownerдля кожного файлу, доданого до архіву (і працює з іншими програмами). Потенційні проблеми виникають, якщо / коли ви розпакуєте недовірений файл tar або архів як root, а не під час його створення.
ilkkachu

7

НІ. Підроблений корінь дозволяє запускати засоби маніпулювання дозволами та звіти, він звітуватиме послідовно. Однак вони фактично не надають цих дозволів. Це буде просто виглядати так, як у вас їх є (підробка). Це нічого не змінить поза оточенням.

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

Це насправді не підвищує дозволи, це підробка. Це не дозволяє вам робити що-небудь (видаляти, писати, читати), що ви не могли зробити інакше. Ви могли б виготовити пакет (теоретично) без нього. Ви можете отримати підроблений звіт ( ls) без нього.

Це не вада безпеки, тому що вона не дозволяє отримати доступ, або все, що без нього не обійтися. Він працює без пільг. Все це доза становить перехоплювати дзвінки на chown, chmodі т.д. Це робить їх відсутність операцій, за винятком того, що він записує те , що трапилося б. Він також перехоплює дзвінки statтощо, щоб він повідомляв про дозволи та право власності з власної внутрішньої бази даних, як би інші команди були виконані. Це корисно, адже якщо ви потім застебнете каталог, він матиме підроблені дозволи. Якщо потім розпакувати як root, то дозволи стануть справжніми.

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

Це тип віртуальної машини: Віртуальна машина, взагалі, може імітувати будь-яке середовище / ОС, але не може нічого зробити з хостом, що не могла зробити будь-яка інша програма. У віртуальній машині ви можете робити все, що завгодно. Ви можете переосмислити систему безпеки, щоб бути однаковою чи різною, однак це все буде існувати на хості, як ресурси, що належать користувачеві / групі процесу, що працює у віртуальному середовищі.


@ ctrl-alt-decor Як я вже писав у коментарі, у * nix не можна встановити власника на корінь від іншого непривілейованого користувача, правда? Отже, для цього повинна бути вагома причина, якщо програма дозволяє, як це не вада безпеки?
ng.newbie

@ ctrl-alt-decor Підроблена програма не дозволяє мені читати / писати / видаляти, але якщо я написала обгортку для системних дзвінків, чи є це причина, що я можу робити і ці операції.
ng.newbie

@ ctrl-alt-decor Отже, єдиною причиною існування фейк-кору є встановлення дозволу на файл для кореневого доступу, не будучи root. Якщо це не вада безпеки, то чому б Linux заборонив це в першу чергу?
ng.newbie

1
Ні, це дозволяє підробляти налаштування користувача будь-якому користувачеві та підробляти деякі інші речі. Спробуйте: запустіть фейк-корт і подивіться на файли ззовні, спробуйте отримати доступ до файлів, чого не слід.
ctrl-alt-delor

4

Тут вже є дві хороші та дуже детальні відповіді, але я лише зазначу, що вступний параграф оригінальної fakeroot сторінки сторінки 1 насправді пояснює це досить чітко і стисло:

fakeroot виконує команду в середовищі, в якому, схоже, є кореневі привілеї для обробки файлів. Це корисно для того, щоб дозволити користувачам створювати архіви (tar, ar, .deb тощо) з файлами в них із кореневими правами / правами власності. Без фальшивки потрібно мати кореневі привілеї, щоб створити складові файли архівів з правильними дозволами та правами власності, а потім упакувати їх, або потрібно було б створити архіви безпосередньо, не використовуючи архіватор.

Fakeroot дозволяє некореневому користувачеві створювати архіви, що містять кореневі файли, що є найважливішою частиною створення та розповсюдження бінарних програмних пакетів у Linux. Без цього fakerootархіви пакетів повинні бути створені під час виконання фактичного кореня, щоб вони містили правильні права власності на файли та дозволи. Це був би ризик для безпеки. Створення та упаковка потенційно ненадійного програмного забезпечення - це величезна експозиція, якщо це зроблено з кореневими приватними програмами. Завдяки fakerootнепривілейованому користувачеві з непривілейованими файлами все ще можна генерувати архіви, що містять файли з кореневою власністю. 2

Але це не є ризиком для безпеки, оскільки фактично нічого в архіві не належить root, поки файли не ВИДАЛЯТЬСЯ . І навіть тоді файли будуть вилучені з недоторканими кореневими правами лише тоді, коли це буде зроблено привілейованим користувачем. Цей крок - коли fakerootархів з підтримкою, що містить файли "root", вилучається привілейованим користувачем - це те, де "підроблений" корінь нарешті стає реальним. До цього моменту жодні фактичні привілеї кореня ніколи не отримуються і не обходять.

Примітки

  1. Fakeroot породив деяких конкурентів / імітаторів, які будуть маскуватися як fakerootби встановлені, включаючи fakeroot-ngта pseudo. Але ІМХО, ані керівна сторінка "імітатора" не є настільки очевидною щодо того, щоб правильно зрозуміти це питання. Дотримуйтесь оригіналу, одного і єдиного fakerootOG
  2. Інші дистрибутиви / Фасувальне-система подолати це, просто НЕ використовуючи кореневу власності в своїх архівах пакетів. Наприклад, у Fedora, програмне забезпечення може збирати, встановлювати та упаковувати непривілейований користувач без необхідності fakeroot. Це все робиться в $HOME/rpmbuild/просторі користувача, і звичайно привілейовані кроки, такі make installяк перенаправлення (через механізми, як --prefixі DESTDIR), до $HOME/rpmbuild/BUILDROOT/ієрархії, яку можна вважати своєрідним «фальшивим» простором (без фактичного використання fakechroot).

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


1
Що стосується вашої першої примітки, fakeroot-ng претензії заміняють її fakeroot, але на практиці вона її не замінила, і AFAIK fakerootвсе ще є інструментом, який використовується в Debian за замовчуванням (коли це необхідно).
Стівен Кітт

@StephenKitt Ага! Спасибі. Мені це було цікаво. Спочатку я був розгублений, тому що я пішов шукати fakerootmanpage, і Google скинув мене на fakeroot-ng's (маскується під fakeroot(1)), і, мабуть, я завищував. Але зараз я бачу, що fakeroot-ng не оновлювався з 2014 року , тоді як fakeroot все ще активний . Очевидно, також є псевдо, який кілька років тому пережив це, але тепер застопорився. Я відповідно підправлю свою відповідь.
FeRD

1
Так, спочатку я також плутався, оскільки сторінка сайту fakerootна Debianfakeroot-ng за замовчуванням веде до версії. Ознайомтеся з останнім абзацом fakeroot-ngдля забавного повороту ;-).
Стівен Кітт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.