SUID, SGID и Sticky Bit в Linux — права доступа, которые незаметно управляют привилегиями

На первый взгляд, права доступа в Linux кажутся простыми — чтение, запись, выполнение. Большинство инженеров на этом останавливаются.
Но в реальных production-системах Linux всё держится на более глубоком уровне доверия: кем процесс является на самом деле, к какой группе он принадлежит и кто имеет право удалять файлы в общих средах.

Вот тут-то и пригодятся SUID, SGID и Sticky Bit.

Эти специальные биты разрешений — не академические понятия. Они активно используются каждый день в реальных системах — sudo от них зависит, общие директории CI/CD зависят от них, и /tmp без них был бы катастрофой с точки зрения безопасности. Неправильное их использование открывает путь к повышению привилегий. Правильное их использование позволяет получить контролируемый доступ без хаоса.

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

Права доступа в Linux обманчиво просты. Все изучают rwx. Все думают, что понимают их.
А потом однажды обычный пользователь запускает команду sudo apt update, и внезапно из ниоткуда появляются процессы, принадлежащие root.

Начнем с того, что вы уже знаете.

Права доступа в Linux обычно выглядят следующим образом:

rwx

Это отвечает только на один вопрос.

«Может ли этот пользователь читать, записывать или выполнять этот файл?»

Большинство людей на этом останавливаются.

А теперь самое удивительное

Вы входите в систему как обычный пользователь (не root) и выполняете следующую команду:

sudo apt update

Внезапно, проверив запущенные процессы, вы видите:

• процесс apt
• принадлежит root

Ваш мозг вполне резонно задаёт вопрос:

«Подождите… У меня нет прав root. Я не переключался на права root. Как же запустился процесс с правами root?»

Это похоже на волшебство.

Что происходит на самом деле (никакой магии)?

Главная идея заключается в следующем.

Linux неважно, кто вы. Ему важно, кем может стать программа.

sudo — всего лишь файл:

/usr/bin/sudo

У этого файла есть специальный бит прав доступа, называемый SUID.

Что на самом деле означает SUID (в одном предложении)

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

А владельцем sudo является:

root

Последовательность действий следующая:

1. Вы (обычный пользователь) запускаете sudo
2. Ядро Linux замечает: установлен SUID
3. Ядро говорит:

• «Только для этой программы используйте права root».

1. sudo запускается от имени root
2. sudo запускает apt update
3. Появляется процесс, принадлежащий root.

Вы так и не стали root-пользователем.
Программа позаимствовала идентификатор root.

Это и есть SUID.

Почему это необходимо (иначе Linux сломается)

Без SUID:

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

Приходилось бы входить в систему как root для каждой операции.

SUID позволяет:

«Выполнить одно привилегированное действие, а затем остановиться».

Это не магия. Это SUID.

А у SUID есть братья — SGID и Sticky Bit — которые незаметно решают:

• кем становится процесс
• кому принадлежат вновь создаваемые файлы
• кому разрешено удалять файлы

3️⃣ «Кому разрешено удалять файлы» → Sticky Bit

Представьте себе /tmp без правил:

• Любой мог бы удалить файлы любого другого пользователя.

Sticky Bit говорит:

«Здесь можно создавать файлы, но удалять можно только свои собственные».

Поэтому /tmp и не превращается в зону боевых действий.

Один образ для запоминания (это закрепляет понимание)

Представьте Linux как рабочее место:

• rwx → доступ к двери
• SUID → временный бейдж начальника
• SGID → правила владения командой
• Sticky Bit → «не трогай чужие вещи»

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

Проще говоря:
права доступа в Linux кажутся простыми, пока вы не заметите, что программы могут временно стать более влиятельными, чем пользователь, запускающий их.
Это происходит потому, что некоторым программам разрешено запускаться от имени своего владельца (SUID), некоторые каталоги принудительно устанавливают совместное владение (SGID), а некоторые общие пространства запрещают пользователям удалять файлы друг друга (Sticky Bit).

Поиск всех SUID-бинарников (базовая проверка безопасности)

На любом сервере — особенно в production — это обязательно:

find / -perm -u=s -type f

Эта команда отвечает на вопрос:

«Какие бинарные файлы могут выдавать себя за своего владельца?»

Если вы видите:

• неожиданные пользовательские бинарные файлы
• файлы внутри каталогов с правами на запись
• скрипты (огромный тревожный сигнал)

Вы немедленно останавливаетесь и проводите расследование.

Установка и удаление SUID (механика)

Установить SUID:

chmod u+s filename

Удалить SUID

chmod u-s filename

Проверять:

ls -l filename

Вы увидите s там, где обычно стоит x.

s vs S: Тонкое, но опасное различие

• rws → исполняемый файл + SUID (активен)
• rwS → SUID установлен, но файл не исполняемый

Заглавная S означает:

• Бинарник не может выполняться
• Но в момент добавления права на выполнение SUID активируется

Это часто происходит случайно во время изменения прав доступа и приводит к скрытому повышению привилегий.

Практический пример использования SUID (реальное, наблюдаемое поведение)

Сценарий

Вам нужны доказательства того, что обычный пользователь может запускать процессы, принадлежащие root, не получая при этом root-прав.

Шаг 1: Войдите в систему как пользователь без прав root.

su - admin

Шаг 2: Выполните команду с правами привилегированного доступа.

sudo apt update

Шаг 3: Наблюдайте за происходящим с другого терминала (root или ec2-user).

ps -ef | grep sudo

Что вы увидите

• Владельцем процесса является root- пользователь.
• Команда была запущена admin

Это происходит потому что:

• /usr/bin/sudo имеет установленный SUID
• Ядро выполняет его от имени root.

Администратор так и не получил права root. Это произошло в процессе.

Риски из реальной жизни: почему никогда не следует устанавливать SUID бездумно.

Установка SUID на:

• скрипты
• бинарные файлы в каталогах с правом записи
• пользовательские программы

Это один из самых быстрых способов скомпрометировать систему.

Если злоумышленник может:

• изменить бинарный файл
• повлиять на переменные окружения
• контролировать входные данные, которые программа обрабатывает некорректно

Он получает root.

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

Если вы не проводили аудит исходного кода, не устанавливайте SUID.

SGID (Set Group ID): совместная работа без хаоса

SGID похож на SUID, но работает на уровне группы.

Это относится к:

• файлам
• каталогам

Именно в каталогах SGID оказывается чрезвычайно полезным.

SGID в файлах (менее распространенный вариант)

Когда SGID задан для исполняемого файла:

• Процесс выполняется с группой, к которой относится файл.

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

SGID в каталогах (в этом и заключается реальная ценность)

Когда для каталога установлен SGID:

• Любой файл, созданный внутри этого каталога, наследует группу этого каталога.
• Независимо от основной группы создателя.

Это решает классическую проблему Linux:

«Почему общие каталоги со временем постепенно перестают работать?»

Пример использования в реальном времени: общее рабочее пространство для инфраструктуры и разработки.

Проблема

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

Решение

SGID на каталоге.

Практический пример использования SGID (AWS EC2)

Войдите как ec2-user:

sudo mkdir /shared
ls -ld /shared
sudo chmod 777 /shared

Создайте пользователя-разработчика:

sudo useradd dev
sudo passwd dev

Переключитесь на разработчика:

su - dev
vim /shared/dev
ls -l /shared

Вы заметите:

• Групповое владение может быть непоследовательным

Исправьте это с помощью SGID

Снова как ec2-user:

sudo chmod g+s /shared
ls -ld /shared

Теперь проведите повторную проверку:

su - dev
touch /shared/dev2
ls -l /shared

Результат

• Все файлы наследуют одну и ту же группу.
• Нет «дрейфа» прав
• Чистая совместная работа

Именно так поддерживаются в порядке общие каталоги сборки, рабочие области CI и зоны выгрузки приложений.

Sticky Bit: Предотвращение случайного (или вредоносного) удаления

Sticky Bit контролирует, кто может удалять файлы, а не кто может их создавать.

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

• Пользователи могут удалять только свои собственные файлы.
• Даже если каталог доступен для записи всем пользователям.

Поэтому /tmp безопасен.

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

Цель

• dev1 и dev2 могут создавать файлы.
• Они не могут удалять файлы друг друга.

Практический пример использования Sticky Bit

Войдите в систему как root:

mkdir /shared2
chmod g+w /shared2
groupadd dev
chgrp dev /shared2

Создайте пользователей:

useradd -g dev dev1
useradd -g dev dev2
passwd dev1
passwd dev2

Без Sticky Bit

su - dev1
touch /shared2/dev1
su - dev2
rm /shared2/dev1

Результат:

• Файл удален ❌

Включаем Sticky Bit

chmod o+t /shared2
ls -ld /shared2

Теперь проведите повторную проверку:

su - dev1
touch /shared2/dev1
su - dev2
rm /shared2/dev1

Вывод:

rm: cannot remove ‘/shared2/dev1’: Operation not permitted

Sticky Bit обеспечивает соблюдение границ владения.

t vs T (Снова тот же шаблон)

• t → выполнение + sticky bit (правильно)
• T → sticky bit без выполнения (ошибка конфигурации)

Для функционирования каталогов необходимы права на выполнение.

Как эти биты используются в реальных системах

• SUID → контролируемое повышение привилегий ( sudo, passwd)
• SGID → общие рабочие пространства, каталоги CI/CD, данные приложений
• Sticky Bit → /tmp, общие каталоги для загрузки, многопользовательские системы

Они помогают:

• уменьшить административную нагрузку
• предотвратить разрастание прав
• обеспечивать безопасность без надзора

Итог (Правила для администраторов)

• Никогда не устанавливайте SUID бездумно.
• Для общих каталогов всегда используйте SGID.
• Для каталогов с доступом для записи всем пользователям всегда используйте Sticky Bit.

Linux не предупреждает вас о неправильном использовании этих элементов.
Он предполагает, что вы точно знаете, что делаете.

И теперь — вы действительно это делаете.

Рассмотрим еще один пример из реальной жизни:

В любой системе Linux:

• Пользователи должны иметь возможность менять свои собственные пароли.
• Но /etc/shadow принадлежит root и недоступен для чтения или записи.

Проверьте:

ls -l /etc/shadow

Типичный вывод:

-rw------- 1 root root /etc/shadow

Итак, очевидный вопрос:

Как обычный пользователь может изменить свой пароль, если он не имеет доступа к /etc/shadow?

Ответ: SUID включен на /usr/bin/passwd

Проверьте права доступа:

ls -l /usr/bin/passwd

Вы увидите:

-rwsr-xr-x 1 root root /usr/bin/passwd

Обратите внимание на s в позиции выполнения для владельца.

Это значит:

• passwd запускается от имени root
• Даже при выполнении обычным пользователем

Что на самом деле происходит под капотом?

1. Пользователь запускает:

• passwd

2. Ядро видит:

• исполняемый файл
• Установлен бит SUID

3. Ядро запускает процесс от имени root.

4. passwd:

• проверяет личность пользователя
• обновляет /etc/shadow
• завершается

5. Привилегии немедленно сбрасываются

Пользователь никогда не получает права root.
Программа временно заимствует права root.

Почему это идеальный пример SUID

Бинарник:

• строго контролируется

• проверенный
• принадлежит root

Действие:

• узко ограничено (только для смены пароля)
• ограниченно по времени
• Поверхность для злоупотребления минимизирована

Это правильное использование SUID.

Что пойдёт не так, если удалить SUID?

Попробуйте (для обучения, не используйте в рабочей среде):

chmod u-s /usr/bin/passwd

Теперь как обычный пользователь:

passwd

Результат:

passwd: Permission denied

Пользователи лишаются возможности менять пароли.
Удобство использования системы мгновенно нарушается.

Почему администраторам важен этот пример?

Потому что это учит важному правилу.

SUID безопасен только тогда, когда бинарник тщательно написан, недоступен для записи и имеет строго ограниченную область действия.

Если кто-то

• скопирует passwd
• модифицирует его
• снова установит SUID

Это мгновенная компрометация root.

Главный вывод в одной строке

sudo показывает, что SUID обеспечивает временную власть.
passwd показывает, что SUID обеспечивает необходимую власть.

Оба существуют для того, чтобы пользователи могли работать, не получая «ключи от королевства».

Заключение

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

Опасность этих разрешений заключается не в их сложности, а в их тонкости. Linux не помешает вам установить их неправильно. Он предполагает, что вы понимаете последствия. Именно поэтому опытные администраторы относятся к SUID как к чему-то опасному, намеренно используют SGID для совместной работы и полагаются на Sticky Bit для обеспечения соблюдения границ владения.

Как только вы по-настоящему разберетесь в этих моментах, права доступа в Linux перестанут казаться произвольными. Вы начинаете видеть в них осознанные контракты доверия между пользователями, процессами и ядром. И в этот момент вы уже не просто используете Linux — вы управляете им.