Возможности (capabilities) в Linux — полное руководство

Что такое возможности в Linux

Возможность (capability) — это отдельное, изолированное право ядра Linux, которое позволяет процессу обходить определённые проверки разрешений ядра. Идея в том, чтобы вместо полного доступа root разложить привилегии на набор более мелких и выдавать только те, которые нужны конкретной службе или утилите.

Коротко: capabilities появились в Linux 2.2 и используются для уменьшения поверхности атаки за счёт точечной выдачи прав.

Важно: SELinux в режимах enforcing может ограничивать использование возможностей даже если они назначены файлу.

Часто используемые возможности

Ниже перечислены некоторые общие capabilities и краткое объяснение того, что они позволяют делать:

• CAP_SYS_ADMIN — даёт широкий набор операций; по возможности избегайте его и применяйте более узкие права.
• CAP_CHOWN — изменение владельца и группы файлов (chown).
• CAP_DAC_READ_SEARCH — обход проверок на чтение файлов и выполнения директорий.
• CAP_DAC_OVERRIDE — игнорирование стандартных DAC-проверок (read/write/execute) для доступа к любым файлам.
• CAP_NET_BIND_SERVICE — привязка к портам ниже 1024.
• CAP_KILL — отправка сигналов процессам без обычных проверок владельца.
• CAP_SYS_NICE — изменение приоритета планирования и niceness.
• CAP_SYS_RESOURCE — переопределение ограничений системных ресурсов (например, лимиты CPU, ограничения квот).

Полный список и подробности см. в man capabilities(7).

Наборы возможностей у файлов и процессов

Файлам назначаются наборы: permitted и effective (помимо inheritable, который редко используют в базовых сценариях). Потоки/процессы имеют дополнительные множества: ambient и bounding. Эти множества определяют сложные правила передачи возможностей при выполнении бинарных файлов; в большинстве практических сценариев для файлов достаточно работать с permitted и effective.

Важно помнить: effective для файла — это фактически один бит, который говорит, может ли процесс автоматически получить объявленные для файла capabilities в эффективный набор при запуске.

Инструменты для работы с capabilities

Два популярных набора утилит:

• libcap (утилиты getcap, setcap, capsh и др.)
• libcap-ng (утилита filecap) — делает некоторые сценарии проще и использует имена возможностей без префикса CAP_

Далее показаны установка и примеры работы с обеими библиотеками.

libcap

Установка

Для Debian/Ubuntu и производных:

apt update
apt install libcap2-bin

Для CentOS:

yum install libcap

Для Fedora:

dnf install libcap

Для Arch Linux:

pacman -Sy libcap

Использование

getcap — показывает, какие capabilities назначены файлу (если они есть):

getcap /path/to/binary

getcap поддерживает рекурсивный поиск через опцию -r, например:

getcap -r /usr 2>/dev/null

Подсказка: перенаправление 2>/dev/null полезно, чтобы не получать сообщения об ошибках «Operation not supported» при попытке читать виртуальные файловые системы (/proc, /sys), которые не поддерживают назначение capabilities.

Назначение capabilities файлу выполняется через setcap. Общий синтаксис:

setcap CAP_NAME+set filename

Пример: добавить CAP_CHOWN и CAP_DAC_OVERRIDE в permitted и effective:

setcap CAP_CHOWN,CAP_DAC_OVERRIDE+ep file1

Удалить все возможности у файла:

setcap -r filename

Ниже — визуальные примеры вывода и использования getcap (изображение). Обратите внимание на подписи и контекст в вашей системе.

libcap-ng

Установка

Для Debian/Ubuntu и производных:

apt update
apt install libcap-ng-utils

Для CentOS:

yum install libcap-ng-utils

Для Fedora:

dnf install libcap-ng-utils

Для Arch Linux:

pacman -Sy libcap-ng

Использование

Утилита filecap в libcap-ng использует имена возможностей без префикса CAP_ (например, NET_ADMIN вместо CAP_NET_ADMIN). Она ожидает полные пути к файлам и всегда устанавливает возможности в наборы permitted и effective.

Просмотр capabilities файла:

filecap /full/path/to/file

Рекурсивный поиск в директории:

filecap /full/path/to/dir

Поиск по всему файловому дереву:

filecap /
filecap -a

Примеры использования filecap показаны на следующем изображении:

Назначение возможности через filecap (путь должен быть полным):

filecap /usr/bin/tac dac_override

Удаление всех возможностей:

filecap /full/path/to/file none

Пример установки и удаления возможностей с помощью filecap показан на изображении:

Практическая методика безопасного назначения возможностей (мини-методология)

1. Анализ: определите, какие операции действительно нужны процессу (например, привязка к порту 80, смена владельца файлов и т.д.).
2. Подбор: выберите минимальный набор capabilities, покрывающий эти операции (например, NET_BIND_SERVICE вместо CAP_SYS_ADMIN).
3. Тестирование: в окружении staging примените setcap/filecap и проверьте поведение сервиса и журналы ошибок.
4. Валидация: проверьте, что процесс получил только нужные возможности (см. Критерии приёмки).
5. Развертывание: примените в production и мониторьте аномалии.
6. Обновление: при обновлениях бинарников контролируйте, сохраняются ли capabilities (packaging, версия файлов).

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

• Компонент работает с назначенными возможностями без необходимости полного root-доступа.
• В системе нет явного превышения привилегий (например, CAP_SYS_ADMIN только если действительно необходимо).
• Процесс имеет ровно те capabilities, которые покрывают его функциональность, и не более.
• Логи и мониторинг не показывают ошибок доступа, связанных с отсутствием разрешений.

Роль-ориентированные чек-листы

Администратор инфраструктуры:

• проверить, какие бинарники имеют SUID/root-права;
• заменить SUID на возможности там, где это безопасно;
• ограничить доступ к утилитам setcap/filecap только доверенным пользователям;
• документировать назначенные возможности в систему конфигов/CM.

Разработчик приложения:

• описать в документации, какие операции требует приложение;
• протестировать поведение приложения при минимальном наборе возможностей;
• при изменениях поведения пересмотреть список необходимых capabilities.

Офис безопасности:

• проводить периодические аудиты файловой системы на предмет необычных capabilities;
• отслеживать установки capabilities в процессе обновлений пакетов.

SOP для безопасного назначения возможности конкретному бинарю

1. Определите полный путь к бинарю: /usr/bin/example
2. На тестовой машине выполните:

setcap CAP_NET_BIND_SERVICE+ep /usr/bin/example
getcap /usr/bin/example

3. Запустите сервис и выполните интеграционные тесты.
4. Если всё стабильно, зафиксируйте изменение в системе контроля конфигураций (Ansible, Puppet, Salt).
5. В production примените те же команды и проверьте логи.
6. Регулярно выполняйте проверку:

getcap -r / 2>/dev/null | grep example

Тесты и случаи приёмки

• Тест 1: сервис успешно привязывается к порту <1024 без root, если назначен CAP_NET_BIND_SERVICE.
• Тест 2: попытка записи в защищённую область должна пройти только при наличии CAP_DAC_OVERRIDE или соответствующих прав.
• Тест 3: после удаления возможностей с помощью setcap -r сервис теряет соответствующие привилегии и логирует ошибки доступа.

Критерий успеха: поведение сервиса соответствует ожиданиям при минимальном наборе capabilities.

Когда возможности не подходят (контрпример)

• Полная изоляция и безопасное окружение требуются по дефолту — тогда лучше использовать контейнеризацию с явными namespace/SECCOMP правилами.
• Когда приложению требуются динамически изменяемые права, сложные зависимости между возможностями и наследованием — может потребоваться архитектурный пересмотр.
• На системах с активным SELinux политики могут блокировать использование назначенных capabilities; в таких случаях нужен совместный анализ SELinux-моделей и возможностей.

Альтернативные подходы

• SUID-бинарники: дают полный root-доступ при запуске — значительно менее безопасно, чем набор capabilities.
• Контейнеры и namespaces: создают изолированное окружение; совместно с ограниченными capabilities дают сильную модель безопасности.
• seccomp: ещё один слой ограничений — полезен для ограничения системных вызовов, но не заменяет capabilities.

Улучшение безопасности: рекомендации и hardening

• Минимизируйте назначаемые capabilities и используйте принцип наименьших привилегий.
• По возможности используйте конкретные, узкие capabilities (например, NET_BIND_SERVICE) вместо CAP_SYS_ADMIN.
• Не давайте возможности исполняемым скриптам или файлам, которые регулярно меняются, без контроля версий и подписи — обновление файла может убрать capability или сделать бинарник уязвимым.
• Ограничьте доступ к инструментам setcap и filecap через права файловой системы и RBAC.
• Мониторьте систему на предмет неожиданных изменений capabilities (аудит файловой системы, CI/CD проверки пакетов).

Совместимость и особенности для разных систем

• SELinux/AppArmor: могут дополнительно ограничивать или блокировать использование возможностей; перед развертыванием проверяйте совместимость политик.
• Обновления пакетов: при установке/обновлении бинарника capability может быть потерян; автоматизируйте повторное применение в пайплайнах конфигурации.
• Файловые системы: некоторые виртуальные fs (proc, sysfs) не поддерживают capabilities — попытка чтения выдаст «Operation not supported».

Приватность и юридические заметки

Capabilities могут давать доступ к персональным данным (чтение файлов, дампов памяти и т.д.). При их использовании соблюдайте местные законы о защите данных и внутренние политики безопасности. Документируйте, какие сервисы получают расширенные права.

Примеры команд проверки процесса

• Проверка возможностей процесса через /proc (пример пути):

cat /proc//status | grep Cap

• Проверка через capsh (часть libcap):

capsh --print

Эти команды помогут убедиться, что процесс действительно имеет или не имеет ожидаемые capabilities.

Краткое резюме

Возможности — мощный и точечный механизм контроля привилегий в Linux. Используйте их, чтобы уменьшить назначение полного root, заменяя SUID и ненужные права на конкретные CAP_*. Всегда тестируйте, документируйте изменения и учитывайте взаимодействие с SELinux/AppArmor.

Важно: всегда применяйте принцип наименьших привилегий и автоматизируйте проверки при обновлениях бинарников.

Вспомогательные материалы и чек-листы

• Быстрая проверка назначенных возможностей:

getcap -r / 2>/dev/null
filecap -a

• Быстрая команда для удаления всех возможностей у файла:

setcap -r /path/to/file

• Шаблон записи в систему конфигурации (Ansible, пример):

- name: Set capability on binary
  command: setcap CAP_NET_BIND_SERVICE+ep /usr/bin/example
  become: yes

–

Изображение: обзор конфигурации возможностей и примеры команд для администрирования на сервере.