Флаги списка управления доступом имеют следующее значение.

Буква в конце каждой строки означает установленное право доступа. Например:

4.2.4 Примеры использования Xcacls.exe

Пример 1

Чтобы заменить ACL для всех файлов и папок в текущей папке, без просмотра вложенных папок и вывода запроса на подтверждение, в командной строке необходимо ввести XCACLS *.* /G administrator:RW /Y.

Пример 2

Добавленные в данном примере АСЕ наследуют АСЕ новых файлов, которые создаются в данной папке. Пользователь Joe получает право читать, изменять, запускать и удалять все файлы, которые создаются в данной папке, но имеет разрешение только на чтение и запись для самой папки. В командной строке необходимо ввести XCACLS *.* /G Joe:RWED;RW /E.

Пример 3

В данном примере устанавливаются разрешения на чтение и запись в папку без создания записи наследования для новых файлов. По этой причине для пользователя Joe АСЕ создаваемым в данной папке файлам не назначается. Для существующих файлов создается АСЕ с разрешениями на чтение. В командной строке необходимо ввести XCACLS *.* /G Joe:R;RW /E.

Заключение

Актуальность моего исследования несомненно подтверждается широким применением списков управления доступа во всех основных операционных системах. Проблема управления доступа, а, в конечном счете и защиты информации, всегда остро стояла как перед рядовыми пользователями, так и перед государственными, военными организациями. Рассмотренные мной модели в различных вариациях способны успешно решать заданные проблемы в зависимости от требований, которые к ним предъявляются. Мне показалось интересным проанализировать методы реализации такой дискреционной модели управления доступом, как ACL, так как эта модель наиболее проста в реализации, т.е. в наименьшие сроки система может приобрести достаточно стабильную и гибкую модель безопасности, кроме того, поддержка ACL реализована в большинстве основных операционных и файловых системах. В данный момент поддержка ACL на уровне приложений реализована не на 100%, но все большее количество программ начинает поддерживать ACL. В этой связи мне показалось интересным привести анализ производительности ACL, при его реализации в различных файловых системах. В случае, если в системе необходима реализация ACL,эта информация может быть полезна для выбора наиболее производительной файловой системы.

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

POSIX.1e ACL являются последовательным расширением модели разрешений POSIX.1. Они поддерживают более хорошо гарантированные и сложные сценарии разрешений, которые сложно или невозможно реализовать в традиционной модели.

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

Сложности в реализации ACL

Что касается POSIX ACL, хотя они являются существенным улучшением, остается много ограничений:

Было бы полезно использование большего числа встроенных разрешений. Для каталогов, разрешения на запись включают права на добавление и удаление файлов. Для файлов такое разрешение позволяет перезаписывать существующее содержимое файла в равной степени как и добавление к этому содержимому новой информации. Для каталогов помогают Sticky биты, но их применимость ограничена. Файловые системы Ext2 иExt3 поддерживают такие флаги, как append (добавить данные) и immutable (имеющий иммунитет), которые могут быть установлены на пофайловой основе. Разрешения ACL имеют по-пользовательский или по-групповой характер.

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

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

В UNIX-подобных системах проще разрешать проблемы, чем в каких либо других популярных системах, но эти ситуации создают определенную сложность и могут содержать баги. Некоторые существующие проблемы могут быть лучше решены в корне. Все расширения должны быть спроектированы осторожно, чтобы упростить интеграцию с существующими системами, такими как Windows/CIFS и NFSv4.

В больших сетях становится проблемой способ, согласно которому UNIX идентифицирует пользователей и группы цифровыми идентификаторами [18]. Как и вся модель разрешений POSIX.1, текущие реализации POSIX.1e ACL основаны на этих уникальных идентификаторах. Обслуживание баз данных пользователей и групп становится более сложным с увеличением размера сети. Протоколы CIFS и NFSv4 решают эту проблемы по-разному.

В CIFS пользователи и группы идентифицируются глобальными уникальными идентификаторами безопасности (security identifier, SID). Процессы обладают числом SID, которое определяет их привилегии. CIFS ACL могут содержать SID из различных доменов.

В NFSv4 пользователи и группы идентифицируются строкой вида “пользователь@домен”. Ожидается, что реализации NFSv4 имеют внутренние представления локальных пользователей, как например уникальные идентификаторы пользователя и группы. ACL могут содержать идентификаторы как локальных, так и нелокальных пользователей и групп.