Дискреционный контроль доступа: ACL и атрибуты [333.1]

Рейтинг: 68.5% · 14 голосов
Специализация LPIC-3 303 (v3.0): криптография и PKI/X.509, шифрование ФС (LUKS/TPM2/Clevis), DNSSEC, hardening хоста, IDS, контроль доступа (SELinux/AppArmor), сетевая безопасность, nftables, VPN, пентест.
Ответить
Аватара пользователя
Sergey_Sysadmin
Сообщения: 134
Зарегистрирован: 11 май 2026, 05:31

Дискреционный контроль доступа: ACL и атрибуты [333.1]

Сообщение Sergey_Sysadmin »

Оглавление курса (16)
  1. Введение в LPIC-3 303: безопасность Linux
  2. X.509 и инфраструктура открытых ключей [331.1]
  3. X.509 для шифрования, подписи и аутентификации [331.2]
  4. Шифрование файловых систем [331.3]
  5. DNS и криптография [331.4]
  6. Усиление защиты хоста [332.1]
  7. Урок 6. Обнаружение вторжений на хосте: AIDE, auditd, сканеры руткитов и OpenSCAP
  8. Контроль ресурсов [332.3]
  9. Дискреционный контроль доступа: ACL и атрибуты [333.1] (вы здесь)
  10. Мандатный контроль доступа: SELinux и AppArmor [333.2]
  11. Усиление сетевой защиты [334.1]
  12. Сетевое обнаружение вторжений
  13. Фильтрация пакетов [334.3]
  14. Виртуальные частные сети (VPN) [334.4]
  15. Уязвимости и угрозы [335.1]
  16. Основы тестирования на проникновение [335.2]
Урок 8. Дискреционный контроль доступа: ACL и атрибуты [333.1]

Классические права Unix описывают доступ всего тремя категориями: владелец, группа, остальные. Этого хватает, пока политика простая. Но как только один файл должен быть полностью доступен двум разным группам, а третьему пользователю - только на чтение, схема rwx упирается в потолок: групповое поле одно, и больше его не растянуть. В этом уроке разбираем POSIX ACL - механизм тонких прав на уровне отдельных пользователей и групп, а также расширенные атрибуты файлов (chattr/lsattr), которые меняют поведение файла независимо от того, кто им владеет.

Изображение

Как это работает

ACL (Access Control List) - это список записей вида субъект:права, который файловая система хранит в расширенном атрибуте system.posix_acl_access. Каждая запись задаёт права для конкретного именованного пользователя (user:alice:rw-), именованной группы (group:devops:r--) или для базовых классов. Базовые записи owner, group, other совпадают с обычными rwx и синхронизированы с ними: меняя ACL владельца, вы меняете и вывод ls -l.

Ключевой и самый коварный элемент - маска (mask). Это верхняя граница эффективных прав для всех именованных пользователей и для группы-владельца. Реальные права = записанные в ACL И (логическое AND) маска. Если в ACL у пользователя стоит rw-, а маска r--, то фактически он получит только чтение. Маска нужна, чтобы старые программы, знающие лишь rwx, могли через chmod g+w грубо отрегулировать все ACL-права разом, не зная о существовании списка.

Дискреционный (discretionary) контроль означает, что решение о доступе принимает владелец объекта по своему усмотрению - в отличие от мандатного (SELinux, AppArmor), где политику задаёт система и владелец её не отменит. ACL - это по-прежнему DAC, просто более гранулярный.

Отдельная история - дефолтные (default) ACL на каталогах. Они не управляют доступом к самому каталогу, а служат шаблоном: каждый новый файл или подкаталог внутри наследует этот набор записей как свой стартовый ACL. Это решает классическую боль общих папок, где у новых файлов постоянно слетают групповые права.

Расширенные атрибуты chattr - это уже не про то, кто имеет доступ, а про то, что вообще можно делать с файлом. Они хранятся в inode и действуют поверх любых прав, включая root. Самые важные: i (immutable) - файл нельзя менять, удалять, переименовывать и создавать на него ссылки даже от root; a (append-only) - в файл можно только дописывать, что незаменимо для логов. Эти флаги может ставить и снимать только root (точнее, процесс с capability CAP_LINUX_IMMUTABLE).

Команды и примеры

Установка инструментов. ACL обычно уже встроены в ядро и util-linux, а вот команды могут лежать в отдельных пакетах:

Код: Выделить всё

# Debian 13 / Ubuntu 24.04
apt install acl attr

# RHEL 10 / Fedora 41+
dnf install acl attr
Файловая система должна монтироваться с поддержкой ACL. На ext4 и XFS это давно включено по умолчанию, явный параметр acl в /etc/fstab указывать не требуется. Проверить можно так:

Код: Выделить всё

tune2fs -l /dev/sda2 | grep "Default mount options"   # ext4
mount | grep " / "                                     # активные опции
Смотрим и задаём ACL. Признак того, что у файла есть ACL - символ + в конце прав в ls -l:

Код: Выделить всё

getfacl report.txt

# Дать пользователю alice чтение и запись
setfacl -m u:alice:rw report.txt

# Дать группе devops только чтение
setfacl -m g:devops:r report.txt

# Несколько правил за один вызов
setfacl -m u:alice:rw,g:devops:r,o::- report.txt

# Снять конкретную запись
setfacl -x u:alice report.txt

# Снести все расширенные ACL, оставить базовые rwx
setfacl -b report.txt
Маска и её эффект. После добавления именованной записи setfacl сам пересчитывает маску. Зафиксировать её вручную:

Код: Выделить всё

setfacl -m m::rx report.txt   # потолок прав - чтение и выполнение
getfacl report.txt
# user:alice:rwx
#       effective:r-x   <- маска срезала запись
Строка effective в выводе getfacl показывает реальные права после применения маски - всегда смотрите именно на неё.

Дефолтные ACL на каталоге. Префикс d: или ключ -d:

Код: Выделить всё

mkdir /srv/shared
setfacl -d -m g:devops:rwx /srv/shared
setfacl -m  g:devops:rwx /srv/shared   # права на сам каталог тоже

# Рекурсивно навести порядок в существующем дереве
setfacl -R -m g:devops:rwx /srv/shared
setfacl -R -d -m g:devops:rwx /srv/shared
Бэкап и восстановление ACL - важно при переносе данных, обычный cp -p их не всегда тащит:

Код: Выделить всё

getfacl -R /srv/shared > acl.bak
setfacl --restore=acl.bak
cp -a src dst    # -a сохраняет ACL и атрибуты, в отличие от cp -p
rsync -aA ...    # ключ -A для копирования ACL
Атрибуты chattr/lsattr:

Код: Выделить всё

chattr +i /etc/resolv.conf      # заморозить - не тронет даже root
lsattr /etc/resolv.conf
# ----i---------e------- /etc/resolv.conf
chattr -i /etc/resolv.conf      # разморозить перед правкой

chattr +a /var/log/audit/audit.log   # только дозапись
Частые грабли
  • Маска тихо срезает права. Пользователь по getfacl видит rwx, но реально работает r-x из-за маски. Всегда читайте строку effective, а не саму запись.
  • chmod g+w на файле с ACL меняет не группу-владельца, а МАСКУ. Это сбивает с толку: кажется, что трогаешь группу, а на деле сдвигаешь потолок для всех именованных записей.
  • Дефолтные ACL применяются только к НОВЫМ файлам. Уже лежащие в каталоге объекты не меняются - их нужно проходить отдельно через setfacl -R.
  • cp -p и mv через границу файловой системы могут потерять ACL. Используйте cp -a или rsync -aA, а перед миграцией делайте getfacl -R в файл.
  • Флаг +i ломает обновления и резервное копирование. Файл с immutable нельзя перезаписать пакетным менеджером, и забытый флаг превращается в загадочную ошибку Operation not permitted даже у root.
  • chattr работает не на всех ФС одинаково. На ext4/XFS - да, а на сетевых и многих временных ФС флаги игнорируются или не поддерживаются.
  • ACL не переживают tar без ключа --acls и архивацию в форматы, которые их не хранят.
Мини-лаба
  • Создайте каталог /srv/team, двух пользователей и группу devops, добавьте пользователей в группу.
  • Поставьте на каталог дефолтный ACL: group:devops:rwx. Создайте внутри файл от одного пользователя и проверьте getfacl - запись devops должна унаследоваться.
  • Третьему пользователю (не в группе) дайте на конкретный файл только чтение через setfacl -m u:bob:r и убедитесь, что писать он не может.
  • Выставьте маску m::r-- и посмотрите, как в getfacl у записи devops появилась строка effective:r-- - объясните, почему запись на запись перестала работать.
  • Сделайте бэкап через getfacl -R, удалите ACL ключом -b, восстановите через --restore и сверьте результат.
  • Поставьте на тестовый файл +i, попробуйте удалить его от root, снимите флаг и удалите.
Контрольные вопросы
  • Как вычисляются эффективные права именованного пользователя при наличии маски ACL и почему запись может оказаться шире фактических прав?
  • Что именно меняет команда chmod g+w на файле, у которого есть расширенные ACL, и почему это часто приводит к ошибкам администрирования?
  • Чем дефолтный ACL на каталоге отличается от обычного и на какие объекты он влияет?
  • Какими ключами setfacl задать рекурсивно и обычный, и дефолтный ACL для существующего дерева каталогов?
  • Чем флаг immutable отличается от снятия всех прав записи и почему его не может обойти root без изменения атрибута?
  • Какие инструменты копирования и архивирования сохраняют ACL, а какие их теряют?
👍5 ❤️1 🔥1 😄 🤔
Аватара пользователя
caffeineredteam
Сообщения: 1
Зарегистрирован: 14 май 2026, 12:50

Re: Дискреционный контроль доступа: ACL и атрибуты [333.1]

Сообщение caffeineredteam »

А если на файле есть и базовые group права rw, и именованная запись для другой группы - какая сработает, когда юзер состоит в обеих? Походу складываются по OR, но маска все равно сверху?
👍 ❤️1 🔥1 😄 🤔2
Аватара пользователя
postgresguru
Сообщения: 1
Зарегистрирован: 27 май 2026, 17:13

Re: Дискреционный контроль доступа: ACL и атрибуты [333.1]

Сообщение postgresguru »

Поймал на проде: поставил +i на конфиг, забыл, через месяц apt upgrade падал с Operation not permitted и я полчаса не мог понять при чем тут права. lsattr спас.
👍2 ❤️1 🔥 😄 🤔
Ответить
← Предыдущая глава
Контроль ресурсов [332.3]
Следующая глава →
Мандатный контроль доступа: SELinux и AppArmor [333.2]

Все главы курса «LPIC-3 303: безопасность Linux»

Поделиться темой: ✈ Telegram VK

Вернуться в «LPIC-3 303: безопасность Linux»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость