SUID, SGID та Sticky Bits – це потужні особливі дозволи, які можна встановити для виконуваних файлів і каталогів у Linux. Ми розглянемо їхні переваги та можливі недоліки.
Вже використовуються на практиці
Створення безпеки в операційній системі, призначеній для багатьох користувачів, породжує певні труднощі. Наприклад, візьмемо просту концепцію паролів. Усі паролі мають бути збережені, щоб при кожному вході користувача система могла порівняти введений пароль зі збереженою копією. Оскільки паролі є ключами доступу до системи, їх потрібно надійно захищати.
У Linux збережені паролі захищені двома способами: вони зашифровані, і лише користувач з правами root має доступ до файлу, де вони зберігаються. Це здається надійним, але створює проблему: якщо доступ до збережених паролів мають лише root-користувачі, як звичайні користувачі можуть змінювати свої паролі?
Підвищення рівня привілеїв
Зазвичай команди та програми в Linux запускаються з тими ж дозволами, що й користувач, який їх запустив. Коли root запускає команду passwd для зміни пароля, вона виконується з правами root. Це означає, що команда passwd має доступ до паролів, збережених у файлі /etc/shadow.
Ідеальний сценарій – це коли будь-який користувач міг би запустити програму 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, а режим u-s його очищає.
Щоб проілюструвати концепцію біта SUID, ми створили просту програму htg. Вона знаходиться в домашньому каталозі користувача dave і не має встановленого біта SUID. При запуску вона показує реальні та ефективні ідентифікатори користувачів (UID).
Реальний UID належить користувачеві, який запустив програму. Ефективний UID – це ідентифікатор, з яким програма поводиться так, ніби її було запущено.
Вводимо наступне:
ls -lh htg
./htg
При запуску програми з локальної копії видно, що реальний та ефективний UID встановлені як 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
Хоча програму запустив Дейв, ефективний UID встановлено як root. Якщо Мері запустила програму, то отримаємо той самий результат, що показано нижче:
htg
Реальний ідентифікатор – mary, а ефективний – root. Програма запускається з правами користувача root.
Біт SGID
Біт Set Group ID (SGID) дуже схожий на біт SUID. Коли біт SGID встановлено для виконуваного файлу, ефективною групою стає група файлу. Процес виконується з правами членів групи файлу, а не з правами користувача, який його запустив.
Ми налаштували нашу програму htg так, щоб вона також показувала ефективну групу. Ми змінимо групу програми htg на групу користувача mary за замовчуванням, mary. Також використаємо символічні режими u-s і 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 встановлено, а група має значення “geek”. Це вплине на будь-які об’єкти, створені в каталозі work.
Вводимо наступне, щоб перейти в каталог work, створити каталог з назвою “demo” і перевірити його властивості:
cd work
mkdir demo
ls -lh -d demo
Біт SGID і група “geek” автоматично застосовуються до каталогу “demo”.
Введемо наступне, щоб створити файл за допомогою команди touch і перевірити його властивості:
touch useful.sh
ls -lh useful.sh
Група нового файлу автоматично встановлюється на “geek”.
Біт Sticky
Свою назву “sticky” цей біт отримав від свого історичного призначення. Коли він встановлений для виконуваного файлу, операційна система зберігає текстові частини виконуваного файлу в swap-файлі, що прискорює повторне використання. У Linux цей біт впливає лише на каталог, його встановлення для файлу не має сенсу.
Коли ви встановлюєте біт sticky для каталогу, користувачі можуть видаляти лише файли, які їм належать в цьому каталозі. Вони не можуть видаляти файли, які належать іншим користувачам, незалежно від того, які дозволи встановлено для цих файлів.
Це дає змогу створити каталог, який усі користувачі, а також процеси, які вони запускають, можуть використовувати як спільне сховище файлів. Файли захищені, оскільки ніхто не може видалити чужі файли.
Створимо каталог під назвою “shared”. Використаємо символічний режим 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 – це приклади каталогів, для яких встановлені всі дозволи на файли для власника, групи та інших користувачів (тому вони виділені зеленим кольором). Вони використовуються як спільні розташування для тимчасових файлів.
Завдяки цим дозволам кожен теоретично має можливість робити все, що завгодно. Проте біт sticky має перевагу, і ніхто не може видалити файл, який йому не належить.
Підсумок
Нижче наведено короткий перелік того, що ми розглянули вище:
SUID працює лише з файлами.
Ви можете застосувати SGID до каталогів і файлів.
Ви можете застосувати біт sticky лише до каталогів.
Якщо індикатори “s”, “g” або “t” відображаються у верхньому регістрі, біт виконання (x) не встановлено.