SUID, SGID і Sticky Bits — це потужні спеціальні дозволи, які ви можете встановити для виконуваних файлів і каталогів у Linux. Ми поділимося перевагами — і потенційними підводними каменями — їх використання.
Вони вже використовуються
Побудова безпеки в багатокористувацьку операційну систему викликає кілька проблем. Візьмемо, наприклад, (здавалося б) базову концепцію паролів. Усі вони мають бути збережені, щоб кожен раз, коли хтось входить у систему, система могла порівнювати введений ним пароль із збереженою копією. Очевидно, оскільки паролі є ключами від королівства, їх потрібно берегти.
У Linux збережені паролі захищені двома способами: вони зашифровані, і лише хтось із правами root може отримати доступ до файлу, який містить паролі. Це може здатися непоганим, але це створює труднощі: якщо доступ до збережених паролів можуть отримати лише люди з правами root, як ті, хто не має цього доступу, змінять свої паролі?
Підвищення вашого статусу
Зазвичай команди та програми Linux запускаються з тим же набором дозволів, що й особа, яка запускає програму. Коли root запускає команду passwd щоб змінити пароль, він працює з правами root. Це означає, що команда passwd може вільно отримати доступ до паролів, збережених у файлі /etc/shadow.
Ідеальною була б схема, за якою будь-хто в системі міг би запустити програму passwd, але щоб програма passwd зберігала підвищені привілеї root. Це дасть можливість будь-кому змінити власний пароль.
Наведений вище сценарій — це саме те, що робить біт Set User ID (SUID). Це запускає програми та команди з дозволами власника файлу, а не з дозволами особи, яка запускає програму.
Ви підвищуєте статус програми
Однак є ще одна складність. Необхідно заборонити людині втручатися в чужий пароль. Linux включає в себе схему SUID, яка дозволяє запускати програми з набором тимчасово запозичених дозволів, але це лише половина історії безпеки.
Механізм контролю, який не дозволяє комусь працювати з паролем іншої особи, міститься в програмі passwd, а не в операційній системі та схемі SUID.
Програми, які запускаються з підвищеними привілеями, можуть становити загрозу безпеці, якщо вони не створені з принципом «безпека за проектом». Це означає, що безпека – це перше, про що ви думаєте, а потім будуєте на цьому. Не пишіть свою програму, а потім намагайтеся надати їй шар безпеки.
Найбільшою перевагою програмного забезпечення з відкритим кодом є ви можете подивитися на вихідний код самостійно або зверніться до надійних експертних оглядів. У вихідному коді програми passwd є перевірки, щоб ви могли побачити, чи є користувач, який запускає програму, root. Допускаються різні можливості, якщо хтось є root (або хтось використовує sudo).
Це це код, який визначає, чи є хтось root.
Нижче наведено приклад, у якому це враховано. Оскільки root може змінювати будь-який пароль, програмі не потрібно турбуватися про перевірки, які вона зазвичай виконує, щоб побачити, які паролі має дозвіл змінити. Отже, для root це пропускає ці перевірки та виходить із функції перевірки.
Використовуючи основні команди та утиліти Linux, ви можете бути впевнені, що в них закладена безпека і що код багато разів перевіряли. Звичайно, завжди існує загроза ще невідомих подвигів. Проте швидко з’являються виправлення чи оновлення, щоб протистояти нововиявленим уразливостям.
Це програмне забезпечення сторонніх розробників — особливо будь-яке з відкритим вихідним кодом — вам потрібно бути дуже обережними при використанні SUID. Ми не кажемо не робити цього, але якщо ви це робите, ви хочете переконатися, що це не піддасть вашу систему ризику. Ви не хочете підвищувати привілеї програми, яка не збирається правильно керувати собою та людиною, яка її запускає.
Команди Linux, які використовують SUID
Нижче наведено кілька команд Linux, які використовують біт SUID, щоб надати команді підвищені привілеї під час виконання звичайним користувачем:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Зверніть увагу, що імена файлів виділені червоним кольором, що вказує на те, що біт SUID встановлено.
Дозволи на файл або каталог зазвичай представлені трьома групами по три символи: rwx. Це означає читання, запис і виконання. Якщо листи є, цей дозвіл надано. Проте, якщо замість літери стоїть дефіс (-), цей дозвіл не надано.
Є три групи цих дозволів (зліва направо): для власника файлу, для членів групи файлу та для інших. Коли для файлу встановлено біт SUID, «s» представляє дозвіл власника на виконання.
Якщо біт SUID встановлено для файлу, який не має можливостей для виконання, це позначає велика буква «S».
Ми розглянемо приклад. Звичайний користувач dave вводить команду passwd:
passwd
Команда passwd пропонує Дейву його новий пароль. Ми можемо використовувати команду ps щоб побачити деталі запущених процесів.
Ми будемо використовувати ps з grep в іншому вікні терміналу і знайдіть процес passwd. Ми також будемо використовувати параметри -e (кожний процес) і -f (повноформатний) із ps.
Вводимо таку команду:
ps -e -f | grep passwd
Повідомляється про два рядки, другий з яких є процесом grep, який шукає команди з рядком «passwd». Але це перший рядок, який нас цікавить, тому що саме його запустив Дейв для процесу passwd.
Ми бачимо, що процес passwd працює так само, як і якби його запустив root.
Встановлення біта SUID
Легко змінити біт SUID за допомогою chmod. Символічний режим u+s встановлює біт SUID, а символічний режим US очищає біт SUID.
Щоб проілюструвати деякі концепції біта SUID, ми створили невелику програму під назвою htg. Він знаходиться в кореневому каталозі користувача dave, і для нього не встановлено біт SUID. Коли він виконується, він відображає реальні та ефективні ідентифікатори користувачів (UID).
Справжній UID належить особі, яка запустила програму. Ефективний ідентифікатор — це обліковий запис, яким програма веде себе так, ніби її було запущено.
Набираємо наступне:
ls -lh htg
./htg
Коли ми запускаємо локальну копію програми, ми бачимо, що справжні та ефективні ідентифікатори встановлені як dave. Отже, вона веде себе так, як має звичайна програма.
Давайте скопіюємо його в каталог /usr/local/bin, щоб інші могли його використовувати.
Ми вводимо наступне, використовуючи chmod, щоб встановити біт SUID, а потім перевіряємо, чи він встановлений:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Отже, програма копіюється, і біт SUID встановлюється. Ми запустимо його знову, але цього разу ми запустимо копію в папці /usr/local/bin:
htg
Незважаючи на те, що Дейв запустив програму, ефективний ідентифікатор встановлюється на користувача root. Отже, якщо Мері запускає програму, відбувається те саме, що показано нижче:
htg
Справжній ідентифікатор — mary, а ефективний — root. Програма запускається з правами користувача root.
Біт SGID
Біт Set Group ID (SGID) дуже схожий на біт SUID. Коли для виконуваного файлу встановлено біт SGID, ефективною групою встановлюється група файлу. Процес виконується з дозволами членів групи файлу, а не з дозволами особи, яка його запустила.
Ми налаштували нашу програму htg, щоб вона також показувала ефективну групу. Ми змінимо групу програми htg на групу користувача mary за замовчуванням, mary. Ми також будемо використовувати символічні режими us і g+s з chown, щоб видалити біт SUID і встановити SGID.
Для цього вводимо наступне:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Ви можете побачити біт SGID, позначений буквою «s», у групах дозволів. Також зверніть увагу, що для групи встановлено значення mary, а ім’я файлу тепер виділено жовтим кольором.
Перш ніж запустити програму, давайте встановимо, до яких груп належать Дейв і Мері. Ми будемо використовувати команду id з параметром -G (групи), для друку всіх ідентифікаторів груп. Потім ми запустимо програму htg від імені dave.
Ми вводимо такі команди:
id -G dave
id -G mary
htg
Ідентифікатор групи за замовчуванням для mary — 1001, а ефективна група програми htg — 1001. Отже, хоча вона була запущена Dave, вона працює з дозволами учасників групи mary. Це те саме, якби Дейв приєднався до групи Мері.
Давайте застосуємо біт SGID до каталогу. Спочатку ми створимо каталог під назвою «work», а потім змінимо його групу на «geek». Потім ми встановимо біт SGID у каталозі.
Коли ми використовуємо ls для перевірки налаштувань каталогу, ми також використовуємо параметр -d (каталог), щоб бачити деталі каталогу, а не його вміст.
Ми вводимо такі команди:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
Встановлено біт SGID і група «гік». Це вплине на будь-які елементи, створені в робочому каталозі.
Ми вводимо наступне, щоб увійти в робочий каталог, створити каталог під назвою «demo» та перевірити його властивості:
cd work
mkdir demo
ls -lh -d demo
Біт SGID і група «geek» автоматично застосовуються до каталогу «demo».
Давайте введемо наступне, щоб створити файл з дотик команду та перевірте її властивості:
touch useful.sh
ls -lh useful.sh
Група нового файлу автоматично встановлюється на «geek».
The Sticky Bit
Свою назву клейка частина отримала від свого історичного призначення. Коли він встановлений на виконуваному файлі, він позначає операційній системі, що текстові частини виконуваного файлу мають зберігатися в swap, що робить їх повторне використання швидше. У Linux цей біт впливає лише на каталог — встановлювати його у файлі не має сенсу.
Коли ви встановлюєте біт sticky для каталогу, люди можуть видаляти лише файли, які належать їм у цьому каталозі. Вони не можуть видаляти файли, які належать комусь іншому, незалежно від того, яку комбінацію дозволів на файли встановлено для файлів.
Це дозволяє вам створити каталог, який кожен — і процеси, які вони запускають — можуть використовувати як спільне сховище файлів. Файли захищені, тому що, знову ж таки, ніхто не може видалити чиїсь файли.
Давайте створимо каталог під назвою «спільний». Ми будемо використовувати символічний режим o+t з chmod, щоб встановити біт sticky у цьому каталозі. Потім ми переглянемо права доступу до цього каталогу, а також каталоги /tmp і /var/tmp.
Ми вводимо такі команди:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Якщо встановлений біт sticky, виконуваний біт «іншого» набору дозволів на файл встановлюється на «t». Назва файлу також виділено синім кольором.
Папки /tmp і /var/tmp — це два приклади каталогів, які мають усі дозволи на файли, встановлені для власника, групи та інших (тому вони виділені зеленим кольором). Вони використовуються як спільні розташування для тимчасових файлів.
З цими дозволами кожен, теоретично, повинен мати можливість робити що завгодно. Однак цей біт замінює їх, і ніхто не може видалити файл, який йому не належить.
Нагадування
Нижче наведено короткий контрольний список того, що ми розглянули вище для подальшого використання:
SUID працює лише з файлами.
Ви можете застосувати SGID до каталогів і файлів.
Ви можете застосувати цей біт тільки до каталогів.
Якщо індикатори «s», «g» або «t» відображаються у верхньому регістрі, виконуваний біт (x) не встановлено.