Лучшие практики обеспечения безопасности файловых систем Linux с помощью специальных разрешений

Специальные разрешения — это одна из тех функций Linux, которые выглядят незначительно в ls -l, но имеют большое значение в производственной среде. Один лишний s на двоичном файле, принадлежащем root, может позволить обычным пользователям выполнять узкую привилегированную задачу. Один пропущенный t в общей директории для загрузки может позволить пользователям удалять файлы друг друга. Один бит SGID в директории проекта может избавить вас от постоянного потока проблем с правами собственности группы.

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

Понимание стандартных разрешений: краткое повторение

Прежде чем изучать специальные разрешения, важно вспомнить стандартную триплетную нотацию (rwx для владельца, группы и остальных). Эти разрешения представлены численно с использованием восьмеричных значений (например, 755 или 644).

• r (Чтение) = 4
• w (Запись) = 2
• x (Выполнение) = 1

Специальные разрешения изменяют это базовое поведение и представлены четвертой ведущей восьмеричной цифрой (4, 2 или 1).

Специальные разрешения: SUID, SGID и Sticky Bit

Специальные разрешения добавляют функциональность, выходящую за рамки стандартного контроля доступа. Обычно они обозначаются в выводе длинного списка (ls -l) символом s или t, заменяющим стандартный флаг x.

Разрешение	Восьмеричное значение	Эффект
SUID (Set User ID)	4	Файл выполняется с разрешениями владельца файла (а не пользователя, запускающего его).
SGID (Set Group ID)	2	Файл выполняется с разрешениями группы файла, или новые файлы наследуют идентификатор группы родительского каталога.
Sticky Bit	1	Предотвращает удаление или переименование файлов, принадлежащих другим пользователям, в общей директории, даже если у них есть разрешение на запись в эту директорию.

1. Set User ID (SUID)

Бит SUID является мощным и потенциально опасным при неправильном использовании. Если он установлен для исполняемого файла, любой пользователь, выполняющий этот файл, запускает процесс с разрешениями владельца.

Практический пример использования: Утилиты, требующие привилегий root для выполнения определенной задачи, но не должны предоставлять пользователю общий доступ к root.

Пример: SUID на /usr/bin/passwd

Команда /usr/bin/passwd обычно требует прав root для изменения защищенного файла /etc/shadow. У нее установлен бит SUID, что позволяет обычному пользователю временно получить привилегии владельца (root) только на время выполнения passwd для смены собственного пароля.

Просмотр SUID: Обратите внимание на s в слоте выполнения владельца:

ls -l /usr/bin/passwd
# Пример вывода: -rwsr-xr-x 1 root root ... /usr/bin/passwd

Установка SUID: Используйте восьмеричное значение 4 в сочетании со стандартными разрешениями (например, 755 становится 4755):

# Предполагая, что 'my_script' принадлежит 'appuser'
chmod 4755 /path/to/my_script

Предупреждение безопасности для SUID: Никогда не устанавливайте бит SUID на оболочки общего назначения (например, /bin/bash) или широкие скрипты обслуживания, которые интерпретируют внешние входные данные. Если скрипту требуются привилегии, обычно безопаснее использовать узкое правило sudoers, небольшую проверенную вспомогательную программу или сервисный API.

Когда вы проводите аудит хоста, файлы SUID заслуживают внимания, потому что они являются преднамеренными пересечениями привилегий:

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdev ограничивает сканирование текущей файловой системой, что полезно, когда /proc, смонтированные резервные копии или сетевые файловые системы сделали бы результат зашумленным. На серверах с отдельными точками монтирования сканируйте каждую реальную файловую систему намеренно.

2. Set Group ID (SGID)

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

A. SGID для исполняемых файлов

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

B. SGID для каталогов (критически важно для общих сред)

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

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

Установка SGID для каталога: Используйте восьмеричное значение 2 в сочетании со стандартными разрешениями (например, 775 становится 2775):

# Установить группу-владельца 'developers' и включить SGID
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project

Это обеспечивает наследование группы, но не гарантирует, что каждый новый файл будет доступен для записи группе. umask пользователя все еще имеет значение. Если участники создают файлы с ограничительным umask, например 077, файлы могут наследовать группу developers, но оставаться недоступными для чтения или записи группой. Для общих каталогов проверьте ожидаемый umask, ACL по умолчанию или настройки создания файлов на уровне приложения:

getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project

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

3. Sticky Bit

Sticky Bit (или атрибут сохранения текста) почти исключительно используется в общих каталогах для контроля удаления файлов.

Если Sticky Bit установлен для каталога, только владелец файла в этом каталоге или пользователь root может удалить или переименовать этот файл, даже если сам каталог разрешает запись для 'остальных' (o+w).

Практический пример использования: Общедоступные общие каталоги, такие как /tmp или папки для загрузки отделов, где пользователи должны иметь возможность управлять только теми файлами, которые они создали.

Пример: Каталог /tmp

Каталог /tmp часто имеет разрешения типа 1777. 1 указывает, что Sticky Bit активен.

ls -ld /tmp
# Пример вывода: drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

t в конце подтверждает, что Sticky Bit установлен. Без него любой пользователь мог бы удалять файлы, созданные другими пользователями в /tmp.

Установка Sticky Bit: Используйте восьмеричное значение 1 в сочетании со стандартными разрешениями (например, 777 становится 1777):

chmod 1777 /var/public_uploads

Комплексное управление: объединение специальных разрешений

Специальные разрешения часто комбинируются. Четвертая ведущая цифра представляет собой сумму желаемых специальных битов (4+2+1 = 7).

Желаемые разрешения	Восьмеричное значение
Стандартные rwxr-xr-x (755)	755
SUID + rwxr-xr-x	4755
SGID + rwxr-xr-x	2755
Sticky Bit + rwxrwxrwx	1777
SUID + SGID + Sticky Bit + rwx (редко необходимо)	7777

Пример объединения SGID и Sticky Bit для общих папок:

Чтобы создать безопасную общую директорию для совместной работы, где все пользователи являются частью группы 'team', новые файлы наследуют группу 'team', и пользователи не могут удалять файлы друг друга:

1. Установите группу-владельца: chgrp team /data/projectX
2. Примените SGID (2) + Стандартные rwx (7) + Sticky Bit (1) $\rightarrow 2+1 = 3$ для специальных битов.
   • Используя явную сумму: SGID (2) + Sticky Bit (1) = 3. Стандартные разрешения 775.
   • Полная команда: chmod 3775 /data/projectX

При просмотре с помощью ls -ld вы должны увидеть как s в позиции выполнения группы, так и t в позиции выполнения остальных:

drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX

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

Распространенные ошибки, приводящие к реальным инцидентам

Самая опасная ошибка — использование SUID для обхода проектирования надлежащей авторизации. Если скрипту обслуживания нужно вращать один файл, принадлежащий приложению, не делайте весь скрипт эффективно root для каждого пользователя. Предоставьте приложению контролируемую сервисную команду, используйте узкое правило sudoers или измените владельца, чтобы учетная запись службы могла выполнять задачу без root.

Другая распространенная ошибка — делать общие каталоги доступными для записи всем без Sticky Bit:

chmod 777 /srv/uploads

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

chmod 1777 /srv/uploads

Для каталогов, принадлежащих команде, 2775 плюс реальная группа часто лучше, чем запись для всех. Добавляйте Sticky Bit только в том случае, если члены команды не должны удалять файлы друг друга. Некоторые команды хотят иметь общие права на очистку; другие — нет. Модель разрешений должна соответствовать этому рабочему процессу.

Резервное копирование и развертывание также могут нарушить специальные разрешения. Некоторые инструменты архивирования и копирования сохраняют режимы по умолчанию; другие — нет, если вы не передадите правильные флаги. После восстановления системы или развертывания двоичного пакета явно проверяйте специальные биты:

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project

Если /tmp возвращается как 0777 вместо 1777, это не косметическое различие. Пользователи могут вмешиваться в файлы друг друга. Если необходимый бит SUID отсутствует в системной утилите, обычные пользователи могут внезапно потерять ожидаемое поведение. Если неожиданный бит SUID появляется в файле в /home, /tmp или пути загрузки приложения, относитесь к нему как к подозрительному, пока не будет доказано обратное.

Аудит без утопания в выводе

Полное сканирование файловой системы может быть зашумленным, особенно на сборочных машинах и рабочих станциях разработчиков. Начните с наиболее важных областей:

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

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

Для каталогов ищите общедоступные для записи пути без Sticky Bit:

sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null

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

Лучшие практики безопасности специальных разрешений

Из-за повышенных привилегий, предоставляемых SUID и SGID, ими необходимо управлять с особой осторожностью.

1. Ограничьте область SUID: Устанавливайте SUID только на скомпилированные двоичные исполняемые файлы, необходимые для стандартных операций (например, passwd, ping). Никогда не применяйте SUID к интерпретируемым скриптам (Shell, Python, Perl), если они не обернуты в безопасный исполняемый файл-обертку, который проверяет входные данные.
2. Регулярный аудит: Периодически сканируйте файловую систему на наличие необычных файлов SUID/SGID с помощью команды find:

   # Найти все файлы с установленным SUID
   find / -perm /4000 2>/dev/null
   # Найти все файлы с установленным SGID
   find / -perm /2000 2>/dev/null
   

3. Используйте SGID для согласованности группы: Предпочитайте SGID ручному управлению правами собственности на файлы группы в общих структурах данных; это автоматизирует наследование группы.
4. Sticky Bit для общедоступных для записи областей: Sticky Bit необходим для любого каталога, предназначенного для общего использования пользователями, где удаление файлов не-владельцами должно быть ограничено (например, /tmp, /var/tmp).
5. Сочетайте SGID с ACL, когда важна совместная работа: SGID обрабатывает права собственности на группу; ACL по умолчанию обрабатывают разрешения, которые получают новые файлы.
6. Отслеживайте пользовательские исключения: Если ваша организация одобряет пользовательский двоичный файл SUID или SGID, запишите цель, владельца, ожидаемый путь и источник развертывания. Таинственная привилегия — это то, что причиняет боль позже.

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