SUID, SGID и sticky в Linux: как работают и как безопасно применять

Содержание

• Быстрое напоминание
• Они уже используются
• Повышение привилегий при запуске
• Вы повышаете статус программы
• Команды Linux, использующие SUID
• Установка бита SUID
• Бит SGID
• Бит sticky
• Риски и меры смягчения
• Когда не использовать SUID и SGID
• Альтернативы: capabilities, sudo, ACL
• Мини‑порядок действий для безопасного развёртывания
• Чеклисты по ролям
• Критерии приёмки и тесты
• Шпаргалка команд и шаблоны
• Пример плана аудита и отката
• Сводка и ключевые выводы

Быстрое напоминание

SUID — Set User ID: при запуске исполняемого файла процесс получает эффективный UID владельца файла. SGID — Set Group ID: при запуске исполняемого файла процесс получает эффективный GID группы файла; при установке на директорию новые файлы наследуют группу. Sticky — защищает файлы в директории от удаления посторонними пользователями: удалять можно только свои файлы.

Важно: эти биты не заботятся о бизнес‑логике программы — они лишь изменяют права выполнения. Без безопасной реализации самой программы бит может дать атакующему повышенные права.

Они уже используются

Многие системные утилиты в Linux работают благодаря SUID/SGID. Типичный сценарий: команда passwd должна менять файл /etc/shadow (который доступен только root). Если обычный пользователь вызывает passwd, сам процесс должен иметь возможность записать /etc/shadow. Решение — установить SUID на сам исполняемый файл passwd, чтобы процесс действовал как root на время выполнения.

Это позволяет пользователям менять собственные пароли без прямого доступа к файлу с паролями. Однако контроль того, что пользователь меняет именно свой пароль и не вмешивается в чужой, реализован внутри самой программы passwd — в логике приложения, а не в механизме SUID.

Повышение привилегий при запуске

Обычно процесс наследует реальные и эффективные UID/GID от пользователя, который его запустил. SUID меняет эффективный UID на UID владельца файла. SGID — аналогично для групп. При этом реальный UID остаётся UID запускающего: это важно для логирования и для некоторых проверок в коде.

Определения в одну строку:

• Реальный UID — владелец процесса (тот, кто запустил программу).
• Эффективный UID — права, которыми на самом деле обладает процесс при проверке доступа.

Вы повышаете статус программы

Утилиты с повышенными правами — опасная поверхность атаки. Если программа реализована небезопасно, злоумышленник может добиться выполнения произвольного кода с повышенными правами. Поэтому правило одно: дать программе повышенные права только в том случае, если её код прошёл аудит или это стандартная утилита из доверенного репозитория.

Пример: passwd проверяет, кто запускает программу, и в зависимости от этого выполняет или пропускает дополнительные проверки. Поэтому системные утилиты, часто используемые и проверенные тысячами разработчиков, обычно безопаснее сторонних бинарников.

Важно: не переносите ответственность на механизм файловых битов. Биты дают права; безопасность обеспечивает код.

Команды Linux, использующие SUID

Ниже — несколько примеров команд, которые часто имеют SUID:

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

В выводе ls-подсветка и буква s в позиции права владельца указывают на SUID. Если S — заглавная, то исполняемый бит владельца не установлен.

Права отображаются тремя триплетами: владелец, группа, остальные (rwx). Биты SUID/SGID/sticky добавляют дополнительные символы в начало/середину строки прав.

Установка бита SUID

Установить и снять SUID можно через chmod с символическими режимами u+s и u-s.

Для демонстрации создадим простую программу htg, которая при запуске показывает реальный и эффективный UID. Исходная программа лежит в домашней директории пользователя dave и изначально SUID не установлен.

Пример команд, которые использовали в демонстрации:

ls -lh htg

./htg

Если запустить локальную копию, и реальный, и эффективный UID будут dave. После копирования в /usr/local/bin и установки SUID:

sudo cp htg /usr/local/bin

sudo chmod u+s /usr/local/bin/htg

ls -hl /usr/local/bin/htg

Теперь при запуске htg обычными пользователями effective UID будет root, хотя real UID останется их собственным.

htg

Если mary запускает программу, real UID = mary, effective UID = root.

Это демонстрирует поведение SUID: программа выполняется с правами владельца файла (root в данном примере).

Бит SGID

SGID работает похоже на SUID, но меняет эффективную группу.

В демонстрации мы поменяли владельца и группу файла htg и переключили биты так, чтобы убрать 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

Теперь ‘s’ отображается в группе. Мы проверяем группы пользователей командой id -G:

id -G dave

id -G mary

htg

Если эффективная группа процесса совпадает с группой mary (например, GID 1001), то при запуске утилита будет действовать как член группы mary даже если запускает dave.

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

Пример:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Внутри:

cd work

mkdir demo

ls -lh -d demo

touch useful.sh

ls -lh useful.sh

Новые объекты наследуют группу geek.

Бит sticky

Исторически sticky при установке на исполняемый файл просил ядро держать текстовую (кодовую) часть в swap для ускорения; в современных системах это неактуально. В Linux sticky применяется только к директориям.

Если на директории стоит sticky, пользователи могут удалять только собственные файлы в этой директории. Это особенно полезно для общих директорий вроде /tmp, где все имеют права на запись, но не должны удалять чужие файлы.

Пример установки:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

В списке прав вместо x для остальных пользователей вы увидите t, если установлен sticky. Папки /tmp и /var/tmp обычно отображаются с полными правами, но с установленным sticky.

Риски и меры смягчения

Риски:

• Уязвимости в программе с SUID/SGID позволяют атакующему эскалировать привилегии.
• SUID/SGID на двоичных файлах с возможностью выполнения внешних команд или записи файлов может привести к получению root‑прав.
• Неправильная конфигурация SGID на директориях может позволить распространение файловой собственности и непреднамеренное общее использование данных.

Меры смягчения:

• Минимизируйте количество SUID/SGID файлов. Поддерживайте инвентаризацию.
• Применяйте принцип наименьших привилегий: владелец SUID‑файла должен иметь минимально необходимый набор прав.
• Предпочитайте POSIX capabilities вместо SUID там, где это возможно (см. ниже).
• Регулярно проверяйте целостность программ и файлов (например, с помощью AIDE или Tripwire).
• Применяйте статический и динамический анализ кода для внутренних утилит.
• Локализуйте и ограничивайте окружение (например, очистка переменных среды при входе в SUID‑программу).
• Ограничьте доступ к путям, где могут быть загружены плагины или библиотеки, используемые SUID‑программой.

Практическое правило: если вы сомневаетесь — не ставьте SUID. Вместо этого опишите задачу и выберите безопасную альтернативу.

Когда не использовать SUID и SGID

Не используйте SUID/SGID для программ:

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

Пример ошибок разработки, которые превращают SUID в уязвимость:

• Неочищенные переменные окружения (LD_PRELOAD, PATH).
• Запись в лог файлы с предсказуемыми именами во временных директориях.
• Использование небезопасных функций работы со строками и путями.

Альтернативы: capabilities, sudo, ACL

1. POSIX capabilities

• Позволяют назначать отдельные привилегии (например, CAP_NET_RAW для ping) бинарникам без необходимости давать полный root через SUID.
• Команда setcap устанавливает capability для файла: sudo setcap cap_net_raw+ep /bin/ping.
• Рекомендуется, когда процессу нужны конкретные привилегии, а не полный root.

2. sudo

• Позволяет тонко контролировать, какие команды и с какими аргументами может запускать пользователь с повышенными привилегиями.
• Используйте /etc/sudoers и встроенные проверки для ограничения операций.

3. ACL (Access Control Lists)

• Предоставляют более гибкие разрешения на уровне файловой системы, но не заменяют потребность в повышенных правах при выполнении «операций на уровне ядра».

4. Политики безопасности (AppArmor, SELinux)

• Могут ограничить поведение SUID‑процессов и снизить эмпирический риск эксплуатации.

Выбор зависит от требований: если процессу нужны всего одна–две специфические привилегии — используйте capabilities; если нужна бизнес‑логика и аудит — sudo; если требуется гибкая файловая модель — ACL.

Мини‑порядок действий для безопасного развёртывания SUID/SGID

Шаги перед выпуском функционала с SUID/SGID:

1. Оценка необходимости: формализуйте цель и альтернативы.
2. Код‑ревью: статический анализ, ручная проверка критичных мест (ввод, путь, системные вызовы, вызов внешних команд, обработка ошибок).
3. Тесты: fuzz‑тестирование, проверка с разными UID/GID, тесты на инъекции в путь и окружение.
4. Настройка окружения: удаление опасных переменных окружения, ограничение PATH, установка безопасных umask.
5. Минимизация прав: владелец файла — минимально привилегированный аккаунт; для SGID — выделенная группа.
6. Развёртывание в тестовом окружении и аудит логов.
7. Постепенное развёртывание и мониторинг.
8. Документирование и создание плана отката.

Важно: автоматизируйте проверки при CI/CD — скрипт может запретить установку SUID на собранные артефакты без одобрения.

Чеклисты по ролям

Системный администратор:

• Провёл аудит всех SUID/SGID файлов: find / -perm /6000 -type f.
• Проверил владельцев и группы для каждого найденного файла.
• Настроил мониторинг изменений прав (inotify или сторонние инструменты).
• Настроил правила для автоматического оповещения при появлении новых SUID/SGID файлов.

Разработчик библиотеки/утилиты:

• Очистил входные данные и пути.
• Не доверяет переменным окружения для библиотек (LD_PRELOAD) при запуске с повышенными правами.
• Выполнил статический анализ и тестирование на граничные случаи.

Оператор безопасности (SecOps):

• Обновил и проверил полиси AppArmor/SELinux для SUID‑утилит.
• Запланировал регулярные ревью кода и pentest для сервисов с повышенными правами.

Критерии приёмки

• Функциональность выполнена и покрыта тестами: unit, интеграционные, fuzz.
• Процедуры очистки окружения и контроля PATH реализованы и описаны.
• Программа не использует динамическую загрузку библиотек из неконтролируемых путей.
• Код прошёл код‑ревью и статический анализ (указать инструменты).
• Права доступа к бинарнику минимальны: владелец и группа корректно настроены.
• Наличие документации и плана отката при уязвимости.

Тесты и сценарии приёмки

Минимальный набор тестов:

• Запуск программы под обычным пользователем: проверить real UID и effective UID.
• Попытка изменить чужой файл/пароль: ожидать отказ.
• Попытка инъекции аргумента, содержащего специальную последовательность: проверка корректной обработки.
• Fuzzing входных параметров и проверка, что программа не падает и не эскалирует права.
• Тест на окружение: LD_PRELOAD и PATH не влияют на поведение.

Шпаргалка команд и шаблоны

Поиск SUID/SGID файлов:

# SUID и SGID файлы
find / -perm /6000 -type f -exec ls -l {} \;

# Только SUID
find / -perm -4000 -type f -exec ls -l {} \;

# Только SGID
find / -perm -2000 -type f -exec ls -l {} \;

Проверка бита sticky на директориях:

find / -perm -1000 -type d -exec ls -ld {} \;

Установка capabilities:

sudo setcap cap_net_raw+ep /bin/ping
getcap /bin/ping

Удаление SUID/SGID:

sudo chmod u-s /path/to/file
sudo chmod g-s /path/to/file

Ограничение sudo для определённой команды в /etc/sudoers:

# Пример: разрешить user1 запускать /usr/local/bin/htg без пароля
user1 ALL=(root) NOPASSWD: /usr/local/bin/htg

Пример плана аудита и отката

Аудит:

1. Запустить скан по всем файловым системам и собрать список SUID/SGID: find / -perm /6000 -type f.
2. Для каждого файла проверить происхождение: пакетный менеджер, собственная разработка или сторонний поставщик.
3. Провести статический анализ и ревью исходников (если доступны).
4. Оценить необходимость каждого SUID/SGID; при сомнении — отключить и протестировать систему.
5. Добавить записи в CMDB/инвентарь и настроить мониторинг изменений.

Откат:

1. Если после удаления SUID функциональность нарушается, временно восстановить SUID, но: включить логирование, ограничить доступ и запланировать срочный аудит.
2. Если уязвимость обнаружена в стороннем пакете — запросить исправление у поставщика и временно заменить пакет альтернативой или ограничить доступ к уязвимой функции.
3. Всегда иметь резервный план восстановления: список команд для восстановления прав и пакетных версий.

Модель принятия решения (Mermaid)

flowchart TD
  A[Нужна ли программе повышенная привилегия?] -->|Нет| B[Не ставить SUID/SGID]
  A -->|Да| C[Можно ли дать минимальную capability?]
  C -->|Да| D[Использовать setcap]
  C -->|Нет| E[Можно ли ограничить через sudo?]
  E -->|Да| F[Использовать sudo с ограничениями и аудит]
  E -->|Нет| G[Нужен SUID/SGID — провести полный аудит кода и окружения]
  G --> H[Развёртывание в тестовой среде и мониторинг]
  H --> I[Продакшн с постепенным rollout]

1‑строчная глоссарий

• SUID: запуск с UID владельца файла.
• SGID: запуск с GID группы файла; при директории наследование группы.
• Sticky: запрет удаления чужих файлов в директории.
• Capability: отдельные привилегии ядра, альтернатива SUID.

Совместимость и переносимость

Разные дистрибутивы Linux поддерживают SUID/SGID одинаково, но поведение инструментов аудита, подсветки и management‑инструментов может отличаться. На системах с продвинутыми политиками безопасности (SELinux, AppArmor) поведение SUID‑программ может ограничиваться дополнительными правилами; при миграции учитывайте правила безопасности и аудитируйте профили.

Краткое объявление для команды (100–200 слов)

SUID, SGID и sticky — это механизмы управления привилегиями в Linux, которые позволяют выполнять программы с правами владельца файла или защищают общие директории от удаления чужих файлов. Они эффективны, но увеличивают риск при небезопасной реализации программ. Перед добавлением SUID/SGID каждая команда должна заполнить форму оценки рисков, выполнить код‑ревью, настроить тестирование (включая fuzz), и согласовать план отката. По возможности заменяйте SUID на POSIX capabilities или ограниченные sudo‑правила. Системные администраторы должны регулярно сканировать систему и хранить инвентарь таких файлов.

Сводка

• SUID и SGID дают процессы права владельца/группы файла; sticky защищает файлы в директории от удаления посторонними.
• Механизмы сами по себе не обеспечивают безопасности — важна логика и реализация программ.
• Используйте capabilities и sudo там, где это возможно.
• Внедряйте SUID/SGID только после аудита, тестирования и документирования, с планом отката.

Ключевые выводы:

1. Минимизируйте SUID/SGID и держите их под контролем.
2. Оценивайте альтернативы и применяйте принцип наименьших привилегий.
3. Автоматизируйте аудит и мониторинг для своевременного обнаружения изменений.