Списки контроля доступа и расширенные атрибуты

Списки контроля доступа (Access Control Lists, ACL). Типичное для UNIX управление пользователями и группами, а также основанные на нем права доступа к каталогам и файлам сохраняются в неизменном виде уже не одно десятилетие. Концепция настолько проста, что ее начинаешь понимать после пары часов изучения. Правда, встречаются случаи, когда этой простой системы недостаточно.

Именно поэтому была разработана более «мелкоячеистая» система управления правами доступа, основанная на так называемых списках контроля доступа (ACL). ACL позволяют установить для файла или каталога любое количество правил, касающихся того, какие пользователи или группы имеют право читать или изменять файл или группу файлов, находящихся в каталоге, а какие пользователи не имеют такого права — эта возможность в системах UNIX уже не предусмотрена. Таким образом, ACL дополняют стандартные права доступа и могут вводить дополнительные права или отменять существующие.

Списки контроля доступа по умолчанию входят в состав ядра Linux, начиная с версии 2.6. Для более ранних версий ядра существуют соответствующие заплатки. В файловых системах btrfs, jfs и xfs списки контроля доступа активны в любом случае. В файловых системах ext, напротив, необходимо использовать mount-параметр acl, чтобы активировать списки контроля доступа. В большинстве дистрибутивов эта функция не выполняется автоматически. Файловый сервер Samba — это важнейшая из тех программ, при работе с которой очень выгодно использовать списки контроля доступа. Благодаря ACL эта программа способна во многом экстраполировать права доступа, существующие в Windows, на Linux.

Ограничения. Тот факт, что ACL предоставляют дополнительные возможности, ни в коем случае не отменяет традиционного управления правами! Для опытных администраторов крупных сетей списки контроля доступа могут обеспечить дополнительную безопасность или как минимум упростить управление сетью, но для большинства пользователей Linux обычного метода управления правами будет вполне достаточно. Если неправильно использовать сложную систему списков контроля доступа, то могут возникнуть всевозможные бреши в сфере безопасности сети. Поэтому в настоящее время и не существует дистрибутивов, в которых списки контроля доступа использовались бы по умолчанию.

Основная проблема заключается в том, что многие программы и команды Linux неправильно работают с ACL. Вполне может случиться так, что в скопированном файле вдруг не окажется информации об ACL, которая присутствует в оригинале. Большинство файловых менеджеров также не могут правильно отображать и изменять списки контроля доступа (Konqueror — приятное исключение из этого правила).

Расширенные атрибуты (EA). Расширенные атрибуты (Extended Attributes, EA) находятся в тесном родстве со списками контроля доступа. Они позволяют сохранять для любых файлов дополнительные сведения в форме пар «атрибут — значение». Так, например, вы можете присвоить текстовому файлу атрибут charset с настройкой utf8, чтобы сохранить таким образом применяемую кодировку. Конечно, это выгодно только тогда, когда существуют программы, способные интерпретировать такую информацию. В зависимости от того, какой файловой системой вы пользуетесь, расширенные атрибуты необходимо активировать с помощью соответствующего mount-параметра; например в случае с файловой системой ext это параметр user_xattr.

Более подробная информация о применении списков контроля доступа и расширенных атрибутов содержится на страницах справки man (acl, getfacl, setfacl, attr(5), getfattr и getsattr).

Предпосылки. В следующих примерах я буду исходить из того, что у вас установлен пакет attr с командами attr, getfattr и setfattr и что вы работаете с файловой системой, в которой активированы списки контроля доступа и расширенные атрибуты. Если вы работаете с файловой системой ext4, то результат выполнения команды mount должен выглядеть так:

user$ mount
...
/dev/sdc5 on /test type ext4 (rw,acl,user_xattr)
...

В иных случаях в следующих примерах вы получите сообщение об ошибке, которое будет гласить примерно следующее: «Операция не может быть выполнена». Чтобы справиться с этим, попробуйте изменить параметр mount в /etc/fstab и заново привязать файловую систему.

Списки контроля доступа

Команда getfacl. В системах, где установлены списки контроля доступа, обычно все равно действуют стандартные принципы управления доступом, которые часто называются минимальным списком контроля доступа. Команда getfacl отображает эти права в виде ACL:

user$ touch файл1
user$ getfacl файл1
# file: файл1
# owner: kofler
# group: kofler
user::rw-
group::r--
other::r--
user$ ls -l файл1
-rw-r--r-- 1 kofler kofler ... файл2

Команда setfacl. С помощью setfacl можно определить новые права доступа. Следующие команды предоставляют пользователю gabi и всем членам группы docuteam доступ к файлу с правом читать и изменять этот файл, однако закрывают пользователю kathrin какой-либо доступ к файлу:

user$ setfacl -m gabi:rw файл1
user$ setfacl -m g:docuteam:rw файл1
user$ setfacl -m kathrin:- файл1

Список прав команды getfacl немного длиннее. Теперь ls показывает на месте прав доступа для членов группы специальную ACL-маску. За буквами, означающими доступ, следует символ +, указывающий на наличие правил ACL.

user$ getfacl файл1
# file: файл1
# owner: kofler
# group: kofler
user::rw-
user:gabi:rw-
user:kathrin:---
group::r--
group:docuteam:rw-
mask::rw-
other::r--
user$ ls -l файл1
-rw-rw-r--+ 1 kofler kofler ... файл1

Как правило, списки контроля доступа применяются для того, чтобы предоставить определенному пользователю доступ к его файлам, не давая такого доступа всем остальным пользователям. В таком случае вам потребуется попросить администратора, чтобы он создал группу, к которой будете принадлежать вы и те пользователи, вместе с которыми вы хотите обрабатывать файлы. При использовании ACL просто нужно выполнить команду setfacl -m пользователь:rw файл.

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

При изменении правила ACL командой setfacl маска автоматически рассчитывается заново так, чтобы могли выполняться все прочие правила ACL. Данная маска отображается с помощью команды getfacl и также учитывается командой ls -l.

Можно явным образом настроить маску с помощью команды setfacl -m m:rwx file, ограничив, таким образом, права ACL. Однако учитывайте, что ваша маска действует лишь до тех пор, пока вы не определите новое правило ACL. В таком случае маска ACL будет автоматически пересчитана (если только вы не предотвратите этого с помощью параметра -n).

Стандартные списки контроля доступа. При работе с каталогами можно установить второй набор правил для стандартных списков контроля доступа. Стандартные ACL не управляют доступом к каталогу, а служат образцом для новых файлов. Любой файл, создаваемый внутри данного каталога, наследует стандартные списки контроля доступа, указанные для этого каталога. При одновременном применении нескольких списков контроля доступа новый каталог с правильно подобранными стандартными ACL может применяться в работе в качестве отправной точки.

Совместимость ACL. Распространение списков контроля доступа сильно осложняется тем, что многие стандартные команды и практически все пользовательские программы просто игнорируют ACL. Если вы просто копируете файл с правилами ACL с помощью команды cp, то в скопированном файле правила ACL не сохранятся. То же самое произойдет, если вы откроете файл в текстовом редакторе OpenOffice или Gimp и сохраните его под другим именем. При использовании команды cp будет полезен параметр -p, но у большинства других команд и программ подобные параметры отсутствуют, либо эти программы вообще не приспособлены к работе с ACL.

Проблемы возникают и при резервном копировании. Команды tar и rsync элиминируют правила ACL. Файловая система CD и DVD не рассчитана на работу с ACL, так что сохраняемая в них информация теряется. Есть два выхода: во-первых, можно применять вместо tar версию star, совместимую с ACL, во-вторых, перед резервным копированием можно создавать отдельный текстовый файл, в который заносятся ACL-правила всех копируемых файлов. После резервного копирования правил ACL восстанавливаются на основании этого файла.

user$ getfacl -R --skip-base . > acl-backup (Сохранение ACL-правил)
user$ setfacl --restore=acl-backup (Восстановление ACL-правил)

Расширенные атрибуты

Команды setfattr и getfattr. На следующих примерах показано, как сохранять атрибуты с помощью команды setfattr и считывать их с использованием getfattr.

user$ touch файл2
user$ setfattr -n user.language -v ru файл2
user$ setfattr --name=user.charset --value=utf8 файл2
user$ getfattr -d файл2
# file: файл2
user.charset="utf8"
user.language="ru"

Команда getfattr обычно возвращает только те атрибуты, чье название начинается с user. Если вы хотите увидеть другие атрибуты, нужно указывать имя атрибута вместе с меткой -n, а образец атрибута — с меткой -m.

user$ getfattr -n security.selinux -d tst
# file: tst
security.selinux="user_u:object_r:user_home_t:s0^000"

Совместимость с расширенными атрибутами. К сожалению, пока практически не существует программ, которые сохраняли бы расширенные атрибуты при копировании, архивировании и т. д. Даже команда cp -p игнорирует атрибуты. При создании резервных копий лучше всего поступать так же, как и при работе с ACL — создавать при копировании текстовый файл со всеми расширенными атрибутами. На основании этого файла можно потом восстановить расширенные атрибуты.

user$ getfattr -R . > ea-backup (Сохранение атрибутов)
user$ setfattr --restore=ea-backup (Восстановление атрибутов)

Возможности

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

Предпосылки. Чтобы можно было реализовать рассмотренные возможности, должны выполняться три предварительных условия.

1. В системе должна работать достаточно актуальная версия ядра (не ниже 2.6.24), и при его компиляции должны быть активированы параметры, связанные с возможностями (CONFIG_SECURITY_CAPABILITIES и CONFIG_SECURITY_FILE_CAPABILITIES).

2. Должна быть установлена библиотека libcap (/lib/libcap* или /lib64/libcap*).

3. Файловая система должна поддерживать расширенные атрибуты, так как именно в виде таких атрибутов сохраняется информация о возможностях. В файловых системах на основе ext дополнительно к этому должна применяться mount-параметр user_xattr.

В большинстве дистрибутивов первые два требования по умолчанию выполняются. Для выполнения третьего условия обычно приходится внести изменения в /etc/fstab.

Getcap и setcap. Для администрирования возможностей применяются команды getcap и setcap. Во многих дистрибутивах их приходится устанавливать дополнительно (пакет libcap-ng-utils).

В следующем примере демонстрируется применение возможностей. Сетевая команда ping в большинстве дистрибутивов снабжена Setuid-битом, поэтому она доступна для обычных пользователей. Если удалить этот бит, то с командой ping сможет работать лишь администратор (root):

root# chmod u-s /bin/ping
user$ ping yahoo.de
ping: icmp open socket: операция запрещена

Теперь можно обойтись без небезопасного бита Setuid. Достаточно с помощью setcap предоставить команде ping доступ к сетевым функциям ядра. getcap позволяет просмотреть, какие возможности теперь будут у команды ping.

root# setcap cap_net_raw=ep /bin/ping
root# getcap /bin/ping
/bin/ping = cap_net_raw+ep.