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

Список сокращений Общие: ACL Access Control List (спискок управления доступом)
ACE Access Control Entry (запись управления доступом; запись в ACL) UID User IDentificator (идентификатор пользователя) GID Group IDentificator (идентификатор группы) POSIX Portable Operating Systems Interface SUID Set User IDentificator SGID Set Group IDentificator MAC Mandatory Access Control (мандатное управление доступом) DACL Discretionary Access Control List (дискреционный список управления доступом) SACL System Access Control List (системный список управления доступом) Файловые системы: UFS Unix File System (файловая система UNIX) NFS Network File System (сетевая файловая система) CacheFS Cache File System LOFS Loopback File System VFS Virtual File System (виртуальная файловая система) CIFS Common Internet File System (общая файловая система Интернет) FAT File Allocation Table (таблица расположения файлов) VFAT Virtual File Allocation Table (виртуальная таблица расположения файлов) NTFS New Technology File System (файловая система новых технологий) Прочие: FIFO First-In-First-Out (FIFO pipe; канал работающий по принципу «первый вошел – первый вышел») HTTP HyperText Transfer Protocol (протокол передачи гипертекстовой информации) IIS Internet Information Services (информационные сервисы интернета) RPC Remote Procedure Call (удаленный вызов процедур) SMB Server Message Block GNU GNU is Not Unix
1. Введение Целью своей работы я ставлю рассмотрение общих принципов и механизмов работы списков управления доступом (ACL), а также их реализации в наиболее популярных операционных системах, подавляющее большинство которых относится к классу UNIX-подобных операционных систем. Так как ACL представляет собой одну из реализаций существующих моделей разграничения прав доступа, то в данной работе также уделено место для краткого описания существующих классов методов контроля над доступом (дискреционного и мандатного), а также рассмотрены основные модели управления доступом (в случае дискреционного управления доступа – модель Харрисона-Руззо-Ульмана, а в случае мандатного – модель Белла-ЛаПадулы и его модификация – модель Биба). Концепция ACL формально не стала стандартом POSIX, а потому здесь будут рассмотрены различные аспекты реализации и использования ACL. В частности такие особенности, как реализация ACL в Linux, Solaris, Windows. Будут рассмотрены различия в способах хранения расширенных атрибутов в различных файловых системах (Ext2, Ext3, XFS, ReiserFS, NTFS и других). 1.1 Альтернативная модель управления доступом Традиционно системы, поддерживающие POSIX [11,2] обладают единой простой, но мощной моделью разрешений файловой системы: каждый объект файловой системы ассоциируется с тремя наборами разрешений, которые определяют права доступа для владельца файла, группы пользователей, к которой принадлежит владелец и для всех остальных пользователей. Каждый набор может содержать права на чтение (read, r), запись (write, w) и выполнение (execute, x). Эта схема реализовывается с применением всего 9 бит для каждого объекта. В дополнение к этим 9 битам в специфических целях также используются биты SUID, SGID и Sticky. Эту модель описывает огромное множество как вводных текстов, так и текстов для профессионалов [19]. Хотя традиционная система крайне проста, она испытывает недостаток в реализации сценариев разрешений, которые обычно используются в UNIX системах. Также системные администраторы сталкиваются порой с ситуациями, когда такая модель уже недостаточна. Такие ситуации требуют неочевидных установок групп, которые не отражают организационной структуры. Только суперпользователь (root) может создавать группы и менять членство пользователей в этих группах. Установка бита SUID может позволить обычным пользователям выполнять некоторые административные задачи, но уязвимости и недоработки в утилитах, реализовывающих такой механизм, могут привести к тому, что система будет скомпрометирована. Некоторые приложения, такие как демоны FTP, реализовывают свои собственные расширения к модели прав доступа файловой системы [15]. В итоге модель прав доступа становится сложной и громоздкой в плане конфигурации и обслуживания, что, в свою очередь, приводит к проблемам безопасной работы системы. Все эти сложности традиционной модели разграничений прав доступа приводят к необходимости поиска альтернативы такой модели. Такой альтернативой стала модель Access Control List (ACL). Далее будет рассмотрена наиболее успешная схема, которая была разработана рабочей группой POSIX 1003.1e/1003.2c. 1.2 Рабочая группа POSIX 1003.1e/1003.2c
Необходимость в стандартизации других смежных областей в безопасности в дополнение к ACL, привела к тому, что была сформирована специальная рабочая группа для определения расширений безопасности внутри POSIX 1003.1. Документы 1003.1e (System Application Programming Interface/Программный интерфейс системных приложений) и 1003.2c (Shell and Utilities/Консоль и утилиты) были специфицированы этой рабочей группой. Рабочая группа фокусировала свое внимание на следующих расширениях POSIX.1: ACL, аудит, совместимость, мандатное управление доступом (MAC).
К несчастью, оказалось, что стандартизация всех этих областей была непосильной задачей. В январе 1998 года спонсирование 1003.1e и 1003.2c прекратилось. Одна часть документов, которая была достаточно проработана, была выпущена рабочей группой, а другая часть была не готова к выпуску в качестве стандартов. Было решено, что драфт 17, последняя версия документов, выпущенных рабочей группой, должен быть выложен для общего доступа. В настоящее время эти документы могут быть найдены на сайте Винфрида Трампера (Winfried Trümper) [27]. Несколько производителей UNIX систем реализовали различные части расширений безопасности и в результате к версии операционной системы добавлялся ярлык “trusted” (доверенный), например Trusted Solaris, Trusted Irix, Trusted AIX. В настоящее время поддержка ACL реализована на различных файловых системах практически на всех UNIX-подобных системах. Некоторые из этих реализаций совместимы с драфтом 17, в то время как остальные совместимы с более ранними версиями. К несчастью, это отразилось в некоторых коренных различиях среди различных реализаций. Проект TrustedBSD (http://www.trustedbsd.org/), возглавляемый Робертом Ватсоном (Robert Watson) реализовал версии ACL, аудита, совместимости и MAC стандарта POSIX.1e для FreeBSD. Реализации ACL и MAC появились в FreeBSD-RELEASE в январе 2003 года. Реализация MAC до сих пор является экспериментальной.
2. Управление доступом 2.1 Общие принципы С самого начала компьютерной эры одной из основных задач для разработчиков информационных технологий стала задача обеспечения безопасности. Ни одна существующая коммерческая или государственная электронная система не может обходиться без защиты собственной информации от несанкционированного доступа. Начиная с 70-х годов прошлого века в мире стали разрабатываться различные концепции и методы защиты информации, что вскоре привело к созданию единообразного подхода к этой проблеме: были разработаны первые политики безопасности. Политика безопасности – свод формальных правил, определяющих обработку, распространение и защиту информации. Модель политики безопасности – формальное представление политики безопасности для определенной системы или класса систем, определяющее методы обработки, распространения и защиты информации. Формальные правила в большинстве моделей определяют следующие требования в порядке важности: 1. Доступность 2. Целостность 3. Конфиденциальность 4. Подотчетность Каждое из требований отвечает за свою область в модели политики безопасности: Доступность – требование, отвечающее за доступ к информации, а именно: • Предоставление доступа легальным пользователям в разрешенных масштабах. • Предотвращение отсутствия такового. • Предотвращение от нелегального доступа. Целостность отвечает за две области: • Целостность информации – обеспечение защиты информации от нелегальных действий в процессе хранения, обработки и передачи. • Целостность системы – отсутствие двойственности в работе системы. Конфиденциальность – требование к защищенности личной и секретной информации, применяется к данным в процессе хранения, обработки и передачи. Является наиболее важным требованием для некоторых типов данных или систем, таких, как секретный ключ или сервер аутентификации. Подотчетность – требование, по которому любое действие можно было бы проследить от начала и до конца. Позволяет обнаружить нелегальное использование системы, обеспечивает защиту систем от ошибок и восстановление системы в случае их возникновения. Все эти требования, в конечном счете, и формируют защищенность, которую в каждом отдельном случае следует понимать лишь как определенный набор требований к вышеизложенным целям. Помимо набора требований одним из важнейших атрибутов модели, непосредственно влияющих на её реализацию, являются предусмотренные в модели методы контроля над доступом к системе. Большинство защищенных методов контроля над доступом к системе делятся на два класса: • Свободный (самостоятельный) контроль над доступом в систему (Discretionary Access Control, DAC) является свободным в том смысле, что владелец или распорядитель информации может самостоятельно менять возможности доступа к своей информации. Характерен для моделей, предназначенных для реализации в коммерческих и научных целях. • Мандатный контроль над доступом (Mandatory Access Control, MAC) в систему означает независимость доступности информации от её владельца. Как правило в подобных случаях контроль за доступом реализуется исходя из свойств самой информации и свойств желающего получить к ней доступ согласно независимым от них обоих правилам. Характерен для моделей, предназначенных для реализации в военных и государственных системах защиты. Строго говоря, критерии определения того, к какому классу относится тот или иной метод контроля над доступом, далеко не всегда дают определенный результат, но являются весьма точными для большинства классических моделей политики безопасности. 2.2 Дискреционное управление доступом Дискреционное управление доступом - это метод ограничения доступа к объектам, который основан на том, что некоторый субъект (обычно владелец объекта) может по своему усмотрению давать другим субъектам или отбирать у них права доступа к объекту. Текущее состояние прав доступа в случае дискреционного управления доступом описывается матрицей, в строках которой перечислены субъекты, а в столбцах - объекты (таблица 1). В клетках, расположенных на пересечении строк и столбцов, записываются способы доступа для субъекта по отношению к объекту, например: чтение, запись, выполнение, возможность передачи прав другим субъектам и т.д. В данном случае каждый элемент матрицы доступа M определяет права доступа -го субъекта к -му объекту (чтение, запись, выполнение и т.п.). Элементы в матрице доступа имеют следующие значения: r - чтение, w - запись, е - выполнение, a – дописать в файл, 0 - нельзя использовать. Таблица 1 – Матрица доступа … r r, w … r r, a 0 … e … … … … … r, w 0 … e Прямолинейное представление подобной матрицы невозможно (поскольку она очень большая), да и не нужно (поскольку она разрежена, то есть большинство клеток в ней пусто). В операционных системах более компактное представление матрицы доступа основывается либо на структуризации совокупности субъектов (владелец/группа/другие у ОС UNIX), либо на механизме списков управления доступом (ACL, Access Control List), то есть на представлении матрицы по столбцам, когда для каждого объекта перечисляются субъекты вместе с их правами доступа. За счет использования метасимволов можно компактно описывать группы субъектов, удерживая тем самым размеры ACL в разумных пределах.
Каждая колонка в матрице может быть реализована как список доступа для одного объекта. Очевидно, что пустые клетки могут не учитываться. В результате для каждого объекта имеем список упорядоченных пар , который определяет все субъекты с непустыми наборами прав для данного объекта. Если матрицу доступа хранить по строкам, то есть каждый субъект хранит список объектов и для каждого объекта список допустимых операций, то такой способ хранения называется capability list (список возможностей). Примерами систем такого рода являются Hydra, Cambridge CAP System. Иногда применяется комбинированный способ. Например, в том же UNIX на этапе открытия файла происходит анализ ACL. В случае благоприятного исхода (у процесса были соответствующие права) файл заносится в список открытых файлов, и при последующих операциях чтения и записи проверки прав доступа не происходят. Список открытых файлов можно рассматривать как capability list. Большинство операционных систем (Windows, Linux) и систем управления базами данных реализует именно дискреционное управление доступом и, как правило, на механизме ACL. Главное его преимущество - гибкость. Главные недостатки - рассредоточенность управления и сложность централизованного контроля, а также оторванность прав доступа от данных, что позволяет копировать секретную информацию в общедоступные файлы. 2.3 Мандатное управление доступом Мандатное управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Метка субъекта определяет уровень его полномочий. Метка объекта - степень его конфиденциальности. Метки безопасности состоят из двух частей: уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так: § особенной важности; § совершенно секретно; § секретно; § несекретно. Категории образуют неурегулированный набор. Их назначение состоит в описании наглядной области, к которой относятся данные. В военной области каждая категория может отвечать, например, определенному виду вооружений. Механизм категорий позволяет разделить информацию "по отсекам", что способствует лучшей защищенности. Субъект не может получить доступ к "чужим категориям", даже если его уровень полномочий - "совершенно секретно". Главная проблема, которую необходимо решать в связи с метками, - это обеспечение их целостности. Во-первых, не должно быть незамеченных субъектов и объектов иначе в такой безопасности появятся проломы, что легко используются. Во-вторых, при любых операциях с данными метки должны оставаться правильными. Особенно это относится к экспорту и импорту данных. Например, печатный документ должен открываться заглавием, которое содержит текстовое и/или графическое представление метки безопасности. Аналогично, при передаче файла по каналу связи должна передаваться и ассоциируемая с ним метка, причем в таком виде, чтоб отдаленная система могла ее проинтерпретировать, несмотря на возможные отличия в уровнях секретности и наборе категорий. Метки безопасности субъектов более подвижные, чем метки объектов. Субъект может во время сеанса работы с системой изменять свою метку, не выходя за выделенные для него рамки. Другими словами, он может сознательно занижать свой уровень полномочий, чтоб уменьшить достоверность неумышленной ошибки. Субъект может читать информацию из объекта, если уровень секретности субъекта не ниже, чем у объекта, а все категории, перечисленные в метке безопасности объекта, присутствующие в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Субъект может записывать информацию в объект, если метка безопасности объекта доминирует над меткой субъекта. В частности, "конфиденциальный субъект" может писать в секретные файлы, но не может - в несекретные (должны также выполняться ограничения на набор категорий). Ни при каких операциях уровень секретности информации не должен снижаться, хотя обратный процесс вполне возможен. Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того, как зафиксированные метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение "позволить доступ к объекту X еще и для пользователя В". Конечно, можно изменить метку безопасности пользователя В, но тогда он получит доступ до многих дополнительных объектов, а не только до X. Принудительное управление доступом реализовано во многих вариантах операционных систем и СУБД с повышенными мероприятиями безопасности. В частности, такие варианты существуют для SunOS и СУБД Ingres. Независимо от практического использования принципы принудительного управления являются удобными методологическим базисом для начальной классификации информации и распределения прав доступа. 2.4 Модели политики безопасности 2.4.1 Модель Харрисона-Руззо-Ульмана Данная модель реализует дискреционное (произвольное) управление доступом субъектов к объектам и контроль за распространением прав доступа. Обозначим: S – множество субъектов (осуществляют доступ к информации) O – множество объектов, содержащих защищаемую информацию - конечное множество прав доступа, означающих полномочия на выполнение соответствующих действий (чтение, запись, выполнение) Принято считать, что , т.е. субъекты одновременно являются и объектами (это сделано для того, чтобы включить в область действия модели отношения между субъектами). Поведение системы моделируется с помощью понятия состояния. - пространство состояний системы M – матрица прав доступа, описывающая текущие права доступа субъектов к объектам (строки – субъекты, столбцы – объекты) - текущее состояние системы Любая ячейка матрицы содержит набор прав доступа s к объекту o, принадлежащих множеству прав доступа R. 2.4.1.1 Поведение системы Поведение системы во времени моделируется переходами между различными состояниями. Переход осуществляется путем внесения изменений в матрицу M с помощью команд следующего вида:
command if in and (условия выполнения команды) in and … in and then (операции, составляющие команду) , где a - имя команды; - параметры команды, являющиеся идентификаторами субъектов и объектов; и - индексы субъектов и объектов в диапазоне от 1 до k; - элементарные операции (выполняются только в том случае, если все условия, означающие присутствие указанных прав доступа в ячейках матрицы M, являются истинными). Элементарные операции В классической модели допустимы только следующие элементарные операции: enter r into (добавление субъекту s права r для объекта o) delete r from (удаление у субъекта s права r для объекта o) create subject s (создание нового субъекта s) create object o (создание нового объекта o) destroy subject s (удаление существующего субъекта s) destroy object o (удаление существующего объекта o) Применение любой элементарной операции op в системе, находящейся в состоянии , влечет за собой переход в другое состояние , которое отличается от предыдущего состояния Q по крайней мере одним компонентом. Выполнение базовых операций приводит к изменениям в состоянии системы, которые описаны в таблице 2. Таблица 2 – Базовые операции модели Харрисона-Руззо-Ульмана Команда Описание enter r into (где ) , если Данная операция вводит право r в существующую ячейку матрицы доступа. Содержимое ячейки рассматривается как множество, т.е. если это право уже имеется, то ячейка не изменяется. Операция enter называется монотонной, т.к. она только добавляет права в матрицу и ничего не удаляет. Предусловие выполнения операции – существование ячейки (существование соответствующих субъекта и объекта). delete r from (где ) , если Данная операция удаляет право r из ячейки матрицы доступа, если оно там присутствует. Содержимое ячейки рассматривается как множество, т.е. если удаляемое право отсутствует в данной ячейке, то данная операция ничего не делает. Операция delete называется немонотонной, т.к. она удаляет информацию из матрицы. Предусловие выполнения операции – существование ячейки (существование соответствующих субъекта и объекта). Create subject s (где ) для всех для всех для всех Операция является немонотонной. Предусловие выполнения операции – отсутствие создаваемого субъекта/объекта. destroy subject s (где ) для всех Операция является немонотонной. Предусловие выполнения операции – наличие субъекта/объекта. create object o (где ) , если для всех Операция является монотонной. Предусловие выполнения операции – отсутствие создаваемого субъекта/объекта. destroy object o (где ) для всех Операция является немонотонной. Предусловие выполнения операции – наличие субъекта/объекта. Описание системы Формальное описание системы состоит из следующих элементов: 1. конечный набор прав доступа
2. конечные наборы исходных субъектов и объектов , где 3. исходная матрица доступа, содержащая права доступа субъектов к объектам - 4. конечный набор команд , каждая из которых состоит из условий выполнения и интерпретации в терминах перечисленных элементарных операций. Поведение системы во времени моделируется с помощью последовательности состояний , причем , где C – множество команд. Попадание системы в то или иное состояние для заданного начального состояния зависит только от условий команд из C и составляющих их операций. Каждое состояние определяет отношения доступа, которые существуют между сущностями системы в виде множества субъектов, объектов и матрицы прав. Должна существовать возможность определить множество состояний системы, в которые она сможет попасть из заданного начального состояния (т.к. для обеспечения безопасности необходимо наложить запрет на некоторые отношения доступа). Это позволит задавать такие начальные условия (интерпретацию команд C, множества объектов , субъектов и матрицу доступа ), при которых система никогда не сможет попасть в состояния, нежелательные с точки зрения безопасности. Следовательно, для построения системы с предсказуемым поведением необходимо для заданных начальных условий получить ответ на вопрос: сможет ли некоторый субъект s когда-либо приобрести право доступа r для некоторого объекта o? Критерий безопасности модели Харрисона-Руззо-Ульмана формулируется следующим образом: Для заданной системы начальное состояние является безопасным относительно права r, если не существует применимой к последовательности команд, в результате которой право r будет занесено в ячейку памяти матрицы M, в которой оно отсутствовало в состоянии . Смысл данного критерия состоит в том, что для безопасной конфигурации системы субъект никогда не получит право r доступа к объекту, если он не имел его изначально. Удаление субъекта или объекта приводит к уничтожению всех прав в соответствующей строке или столбце матрицы, но не влечет за собой уничтожение самого столбца или строки и сокращение размера матрицы. Следовательно, если в какой-то ячейке в начальном состоянии существовало право r, и после удаления субъекта или объекта, к которым относилось это право, ячейка будет очищена, но впоследствии появится вновь (в результате создания субъекта или объекта), и в эту ячейку с помощью соответствующей команды enter снова будет занесено право r, то это не будет означать нарушения безопасности. Из критерия безопасности следует, что для данной модели ключевую роль играет выбор значений прав доступа и их использование в условиях команд. Хотя модель не налагает никаких ограничений на смысл прав и считает их равнозначными, те из них, которые участвуют в условиях выполнения команд, фактически представляют собой не права доступа к объектам, а права управления доступом, или права на осуществление модификаций ячеек матрицы доступа. Таким образом, данная модель описывает не только доступ субъектов к объектам, но и распределение прав доступа от субъекта к субъекту, т.к. именно изменение содержания ячеек матрицы доступа определяет возможность выполнения команд (в том числе команд, модифицирующих саму матрицу доступа), которые потенциально могут привести к нарушению критерия безопасности. Положительные стороны модели Харрисона-Руззо-Ульмана: § данная модель является простой в реализации (т.к. не требует применения сложных алгоритмов) § данная модель является эффективной в управлении (т.к. позволяет управлять полномочиями пользователей с точностью до операции над объектом) § критерий безопасности данной модели является весьма сильным в практическом плане (т.к. позволяет гарантировать недоступность определенной информации для пользователей, которым изначально не выданы соответствующие полномочия) Отрицательные стороны модели Харрисона-Руззо-Ульмана: § доказано, что в общем случае не существует алгоритма, который может для произвольной системы, ее начального состояния и общего правила r решить, является ли данная информация безопасной § существует уязвимость к атаке с помощью “троянского коня” (т.к. в дискреционных моделях контролируются только операции доступа субъектов к объектам, а не потоки информации между ними). 2.4.2 Модель Белла - Ла-Падулы Первой моделью системы безопасности стала модель Белла - Ла-Падулы (Bell-LaPadula model), созданная в 1973-74 годах в MITRE в городе Белфорде в штате Массачусетс по заказу военно-воздушных сил США. В 1976 году она была дополнена до использования в пределах концепции MULTICS (информационно-вычислительная система с мультиплексированием каналов передачи данных), в 1986 году адаптирована для использования в сетевых системах. На протяжении 70-х годов оставалась главной моделью политики безопасности и оказала значительное влияние на формирование TCSEC. В изначальном варианте модель Белла – Ла-Падулы предусматривала возможность только мандатного управления доступом. Мандатная модель управления доступом основана на правилах секретного документооборота, принятых в государственных и правительственных учреждениях многих стран. Основным положением политики безопасности является назначение всем участникам процесса обработки защищаемой информации и документам, в которых она содержится, специальной метки (секретно, совершенно секретно и т.д.). Такая метка называется уровнем безопасности. Все уровни безопасности упорядочиваются с помощью установленного отношения доминирования. Контроль доступа осуществляется в зависимости от уровней безопасности взаимодействующих сторон на основании двух правил:
1. уполномоченное лицо (субъект) имеет право читать только те документы, уровень безопасности которых не превышает его собственный уровень безопасности 2. уполномоченное лицо (субъект) имеет право заносить информацию только в те документы, уровень безопасности которых не ниже его собственного уровня безопасности
Таким образом, мандатные модели управляют доступом неявным образом – с помощью назначения всем сущностям системы уровней безопасности, которые определяют все допустимые взаимодействия между ними. Следовательно, мандатное управление доступом не различает сущностей, которым присвоен одинаковый уровень безопасности, и на их взаимодействия ограничения отсутствуют. Поэтому в тех ситуациях, когда управление доступом требует более гибкого подхода, мандатная модель применяется совместно в какой-либо дискреционной, которая используется для контроля за взаимодействиями между сущностями одного уровня и для установки дополнительных ограничений, усиливающих мандатную модель. Обозначим: S – множество субъектов (осуществляют доступ к информации) O – множество объектов, содержащих защищаемую информацию Принято считать, что , т.е. субъекты одновременно являются и объектами (это сделано для того, чтобы включить в область действия модели отношения между субъектами) - множество прав доступа, означающих полномочия на выполнение соответствующих действий (чтение, запись) L – множество уровней безопасности L - решетка уровней безопасности (это формальная алгебра , где оператор £ определяет частичное нестрогое соответствие порядка для базового множества уровней безопасности L) V – множество состояний системы, которое представляется в виде набора упорядоченных пар (F,M), где M – матрица доступа, отражающая текущую ситуацию с правами доступа субъектов к объектам (содержание матрицы аналогично матрице прав доступа в модели Харрисона-Руззо-Ульмана, но набор прав ограничен правами read и write) F – функция уровня безопасности - модель системы, где - начальное состояние системы - функция перехода, которая в ходе выполнения запросов переводит систему из одного состояния в другое; система, находящаяся в состоянии при получении запроса , переходит в следующее состояние ; состояние v достижимо в системе Û для ; тривиально достижимо Уровни безопасности субъектов и объектов задаются с помощью функции уровня безопасности , которая ставит в соответствие каждому объекту и субъекту уровень безопасности, принадлежащий множеству уровней безопасности L, на котором определена решетка L. 2.4.2.1 Решетка уровней безопасности L Решетка уровней безопасности L - это формальная алгебра , где оператор £ определяет частичное нестрогое соответствие порядка для базового множества уровней безопасности L (т.е. оператор £ - антисимметричен, транзитивен и рефлексивен). Отношение £ на L: 1) рефлексивно, если ; Нет смысла запрещать потоки информации между сущностями одного и того же класса (сущности одного класса с точки зрения безопасности содержат одинаковую информацию). 2) антисимметрично, если ; Антисимметричность необходима для удаления избыточных классов (если информация может передаваться как от сущностей класса A к сущностям класса B, так и наоборот, то классы A и B содержат одноуровневую информацию и сточки зрения безопасности эквивалентны классу (AB)). 3) транзитивно, если ; Если информация может передаваться от сущностей класса A к сущностям класса B, а также от сущностей класса B к сущностям класса C, то очевидно, что она будет также передаваться от сущностей класса A к сущностям класса C. Свойство решетки: Для каждой пары и элементов множества L можно указать единственный элемент наименьшей верхней границы и единственный элемент наибольшей границы. Эти элементы также принадлежат L и обозначаются с помощью операторов · и Ä соответственно: 1) Для пары сущностей x и y, обладающих уровнями безопасности a и b соответственно, обозначим наибольший уровень безопасности их комбинации как , при этом и . Тогда, если существует некоторый уровень c такой, что и , то должно иметь место отношение , поскольку - это минимальный уровень субъекта, для которого доступна информация как из x, так и из y. Следовательно, должен быть наименьшей верхней границей a и b.
2) Для пары сущностей x и y, обладающих уровнями безопасности a и b соответственно, обозначим наименьший уровень безопасности их комбинации как , при этом и . Тогда, если существует некоторый уровень c такой, что и , то должно иметь место отношение , поскольку - это максимальный уровень субъекта, для которого разрешена передача информации как в x, так и в y. Следовательно, должен быть наибольшей нижней границей a и b.
Смысл этих определений состоит в том, что для каждой пары элементов всегда можно указать единственный элемент, ограничивающий ее сверху или снизу таким образом, что между ними и этим элементом не будет других элементов. Функция уровня безопасности F назначает каждому субъекту и объекту некоторый уровень безопасности из L, разбивая множество сущностей системы на классы, в пределах которых их свойства с точки зрения модели безопасности являются эквивалентными. Тогда оператор £ определяет направление потоков информации (если , то информация может передаваться от элементов класса A к элементам класса B). Использование решетки для описания отношения между уровнями безопасности позволяет использовать в качестве атрибутов безопасности (элементов множества L) не только целые числа, для которых определено отношение “меньше или равно”, но и более сложные составные элементы. 2.4.2.2 Классическая мандатная модель Белла-ЛаПадулы В мандатных моделях функция уровня безопасности F вместе с решеткой уровней определяют все допустимые отношения доступа между сущностями системы. Состояния системы делятся на: — безопасные (отношения доступа не противоречат установленным в модели правилам) — небезопасные (правила нарушаются, и происходит утечка информации) Состояние (F,M) называется безопасным по чтению (или просто безопасным) тогда и только тогда, когда для каждого субъекта, осуществляющего в этом состоянии доступ чтения к объекту, уровень безопасности этого субъекта доминирует над уровнем безопасности этого объекта: . Состояние (F,M) называется безопасным по записи (или *-безопасным) тогда и только тогда, когда для каждого субъекта, осуществляющего в этом состоянии доступ записи к объекту, уровень безопасности этого объекта доминирует над уровнем безопасности этого субъекта: . Состояние безопасно тогда и только тогда, когда оно безопасно и по чтению и по записи. Критерий безопасности модели Белла-ЛаПадулы: Система безопасна тогда и только тогда, когда безопасны ее начальное состояние и все состояния, достижимые из путем применения конечной последовательности запросов из R. Основная теорема безопасности модели Белла-ЛаПадулы: Система безопасна тогда и только тогда, когда: a) начальное состояние безопасно и b) для любого состояния v, достижимого из путем применения конечной последовательности запросов из R таких, что , и , для каждого и выполняются следующие условия: 1) если и , то 2) если и , то 3) если и , то 4) если и , то Таким образом, по утверждению теоремы система с безопасным начальным состоянием является безопасной тогда и только тогда, когда при любом переходе системы из одного состояния в другое не возникает никаких новых и не сохраняется никаких старых отношений доступа, которые будут небезопасны по отношению к функции уровня безопасности нового состояния. Недостатки основной теоремы безопасности Белла-ЛаПадулы состоят в том, что: § данная теорема является избыточной по отношению к определению безопасного состояния, т.к. ограничения, накладываемые теоремой на функцию перехода, совпадают с критериями безопасности состояния § из теоремы следует только то, что все состояния, достижимые из безопасного состояния при определенных ограничениях, будут в некотором смысле безопасными, но при этом не гарантируется, что процесс осуществления перехода будет безопасным. Таким образом, можно найти такую систему (Z-систему), в которой при попытке низкоуровнего субъекта прочитать информацию из высокоуровнего объекта будет происходить понижение уровня объекта до уровня субъекта, и осуществляться чтение. Функция перехода Z-системы удовлетворяет ограничениям основной теоремы безопасности в смысле критерия Белла-ЛаПадулы, но любой пользователь системы сможет прочитать любой файл, что несовместимо с безопасностью в обычном понимании. Для гарантирования безопасности во время перехода между состояниями необходимо регламентировать изменения уровней безопасности во время перехода от состояния к состоянию с помощью дополнительных правил.
2.4.3 Модель Биба. Последующим расширением модели Белла - Ла-Падулы стала модель Биба (Biba Model), разработанная в 1977 году. Целью создания модели стало добавление в модель Белла - Ла-Падулы целостности. Задача была реализована путем добавления к субъектам и объектам уровня целостности и запрета общения субъектов и объектов разных уровней.
Для дополнительного управления целостностью введены понижающие водяные знаки (нарушающие запрет на общение): § Если субъект читает объект более низкого уровня, то его уровень целостности снижается до уровня целостности объекта. § Если субъект дополняет объект более высокого уровня, то уровень целостности объекта снижается до уровня целостности субъекта. Модель не только несет в себе достоинства и недостатки модели Белла – Ла-Падулы, но и добавляет собственные. Основной недостаток модели состоит в том, что введение уровней целостности только ограничивает возможности доступа субъектов к объектам, создавая либо значительную изоляцию между уровнями целостности, либо после определения уровней целостности этот уровень может только понижаться, что само по себе лишает его управляемости, и как следствие функциональности. Область применения модели Биба так же не выходит за пределы военных организаций.
3. ACL в UNIX-подобных операционных системах 3.1 Общие принципы и положения 3.1.1 Принципы работы ACL Традиционная модель разграничений прав доступа в файловых системах согласно POSIX определяет 3 класса пользователей: владелец, группа-владелец и остальные. Определенные права доступа: чтение (read, r), запись (write, w) и выполнение (execute, x). В этой модели класс разрешений владельца определяет привилегии доступа для владельца файла, разрешения для группы-владельца – для группы пользователей, в которую входит владелец файла, разрешения для остальных – для всех остальных пользователей (которые не вошли в первые два пункта). Команда ls –l показывает разрешения для доступа для владельца, группы и остальных в первой колонке своего вывода (например, запись “-rw-r----” соответствует обычному файлу, который владелец может просматривать и редактировать, группа – только просматривать, а остальные пользователи не имеют никаких прав на доступ к этому файлу). ACL состоит из набора записей (ACE). Каждый из трех классов пользователей представлен в виде ACE. Разрешения для дополнительных пользователей и групп содержатся в дополнительных ACE. Таблица 3 показывает определенные типы записей и их текстовые представления. Каждая из этих записей состоит из типа, квалификатора, который определяет к какому пользователю или группе применяется запись, и набора разрешений (тип:квалификатор:разрешения). Квалификатор отсутствует для записей, которые в нем не нуждаются. ACL, эквивалентный файловым битам доступа, называется минимальным ACL. Он состоит из трех записей. ACL с более чем тремя записями называется расширенным ACL. Расширенные ACL также содержат запись-маску и могут содержать любое (ограничивается конкретной реализацией ACL для конкретной файловой системы, где существует ограничение на максимальное число записей в одном ACL) количество записей для имеющихся пользователей и групп. Таблица 3 – Типы записей ACL Тип записи (ACE) Текстовое представление Владелец user::rwx Именованный пользователь user:name:rwx Группа владелец group::rwx Именованная группа group:name:rwx Маска mask::rwx Остальные other::rwx Записи именованных пользователей и групп относятся к классу групп, наряду с записью группы владельца. В отличие от модели разрешений POSIX.1, класс группы сейчас может содержать ACE с различными наборами разрешений, таким образом, класс разрешений группы сам по себе более не является достаточным для детального разграничения прав доступа для всех ACE, которые он содержит. Более того, смысл класса разрешений группы переопределен: согласно новой семантике, они определяют верхнюю грань разрешений, которую каждая запись класса групп будет гарантировать. Это свойство верхней грани гарантирует, что приложения POSIX.1, не знающие об ACL, не смогут нежданно и негаданно гарантировать дополнительные разрешения в случае поддержки ACL. В минимальном ACL класс разрешений группы идентичен разрешениям группы-владельца. В расширенном ACL класс группы может содержать записи для дополнительных пользователей и групп. Это может создать проблему: некоторые из этих дополнительных записей могут содержать разрешения, которые не содержаться в записи группы-владельца, и, таким образом, запись разрешений для группы-владельца может отличаться от класса разрешений группы. Эта проблема решается введением записи-маски. В минимальном ACL класс разрешений групп совпадает с записью разрешений для группы-владельца. В расширенном ACL класс разрешений групп совпадает с записью-маской разрешений, тогда как запись группы-владельца все еще определяет разрешения для группы-владельца. Рисунок 1 показывает эти два случая. Рисунок 1: Соответствие между ACE и файловыми битами прав доступа Когда приложение изменяет класс разрешений для владельца, группы или остальных (например, команда chmod(1)), соответствующая ACE также изменяется. Подобным образом, когда приложение изменяет класс разрешений ACE, соответствующей одному из классов пользователей, изменяется разрешение для этого класса. Класс разрешений группы определяет верхнюю грань разрешений, гарантированных записью класса групп. Случай минимального ACL тривиален. В случае расширенного ACL это реализовывается разрешениями записи-маски: эффективными будут разрешения в записях, относящихся к классу группы, который также присутствуют в записи-маске. Разрешения, которые отсутствуют в записи-маске не оказывают никакого эффекта. См. таблицу 4. Таблица 4: Маскировка разрешений Тип ACE Текстовое представление Разрешения Именованный пользователь user:joe:r-x r-x Маска mask::rw- rw- Эффективное разрешение r- Записи владельца и остальных не принадлежат к классу групп. Их разрешения всегда эффективны и никогда не маскируются. 3.1.2 ACL по-умолчанию До сих пор рассматривались ACL, определяющие текущие разрешения для доступа к объектам файловой системы. Этот тип называется ACL доступа (access ACL). Другой определенный тип называется ACL по-умолчанию (default ACL). Он определяет разграничения прав доступа к объектам файловой системы, которые наследуются у родительского каталога в процессе создания объекта. Только каталоги могут быть ассоциированными с ACL по-умолчанию. ACL по-умолчанию для объектов, отличных от каталогов, не имеют никакого смысла, поскольку никакие объекты файловой системы не могут быть созданы внутри объекта, отличного от каталога. ACL по-умолчанию напрямую не участвует в процессе проверки прав доступа.
Когда каталог создается внутри другого каталога, имеющего ACL по-умолчанию, новый каталог наследует ACL доступа и ACL по-умолчанию каталога-родителя. Объекты, не являющиеся каталогами, наследуют ACL по-умолчанию каталога-родителя в качестве своего ACL доступа. Разрешения наследованного ACL доступа далее модифицируются параметром режима доступа, который имеется в каждом системном вызове создания объекта файловой системы. Этот параметр состоит из 9 битов разрешений, которые представляют собой классы разрешений для владельца, группы и остальных. Эффективным разрешением для каждого класса устанавливается пересечение разрешений, определенных для класса в ACL и в параметре режима доступа. Если каталог-родитель не имеет ACL по-умолчанию, разрешения нового файла определятся согласно тому, как это рекомендовано в POSIX.1. Эффективными разрешениями устанавливаются разрешения, определенные параметром режима доступа за исключением тех, которые установлены текущем параметром umask (user mask, маска пользователя). Umask не оказывает никакого эффекта в случае, если ACL по-умолчанию определен. 3.1.3 Алгоритм проверки прав доступа Процесс запрашивает доступ к объекту файловой системы. Сначала выбирается ACE, которая в наибольшей степени совпадает с запросом процесса. ACE просматриваются в следующем порядке: владелец, именованный пользователь, группа (группа-владелец или именованная группа), остальные. Доступ определяется только одной единственной ACE. Далее проверяется, содержит ли соответствующая ACE достаточные разрешения на доступ. Процесс может быть членом более чем одной группы, то есть ему могут соответствовать несколько ACE. Если какая-нибудь из этих ACE содержит необходимые разрешения, то она и выбирается. Если ни одна ACE не содержит достаточных разрешений, то в доступе будет отказано независимо от выбора ACE. Алгоритм проверки прав доступа может быть описан в псевдокоде следующим образом: 1. If UID процесса совпадает с UID владельца Þ доступ будет определяться ACE владельца else if UID процесса совпадает с квалификатором в одной из ACE именованных пользователей Þ доступ будет определятся этой ACE else if один из GID процесса совпадает с GID группы-владельца и ACE группы владельца содержит необходимые разрешения Þ доступ будет определяться этой ACE else if один из GID процесса совпадает с квалификатором одной из ACE именованной группы и эта ACE содержит необходимые разрешения Þ доступ будет определяться этой ACE else if один из GID процесса совпадает GID группы-владельца или одной из именованных групп, но ни одна из этих ACE не содержит необходимых разрешений Þ в доступе будет отказано else доступ будет определяться ACE для остальных пользователей и групп. 2. If соответствующая ACE (выбранная на предыдущем этапе) – это либо ACE владельца, либо ACE остальных и она содержит необходимые разрешения Þ доступ предоставляется else if соответствующая ACE – это ACE именованного пользователя, группы-владельца или именованной группы и она содержит необходимые разрешения и запись-маска также содержит необходимые разрешения (или запись-маска отсутствует) Þ доступ предоставляется else в доступе будет отказано 3.2 ACL в Linux 3.2.1 Статус ACL в Linux Патчи, которые реализовывают ACL драфта 17 POSIX 1003.1e доступны для множества версий Linux уже несколько лет. Они были добавлены в версию 2.5.46 ядра Linux в ноябре 2002 года. Текущие дистрибутивы Linux до сих пор основаны на стабильной ветке ядер версии 2.4.x. Консорциум SuSE и United Linux интегрировал патчи ACL для ядер версии 2.4.x раньше остальных, и, таким образом, их текущие продукты предоставляют наиболее полную поддержку ACL в Linux на сегодняшний день. Командные утилиты getfacl(1) и setfacl(1) в Linux не строго соответствуют драфту 17 стандарта POSIX 1003.2c. Это несоответствие выражается в основном в том, каким образом эти утилиты устанавливают ACL по-умолчанию. Основные файловые системы, для которых реализована поддержка ACL в Linux, это Ext2, Ext3, IBM JFS, ReiserFS и SGI XFS. 3.2.2 Пример ACL доступа Начнем с создания каталога и проверки разрешений на доступ к нему. Параметр umask определяет, какие разрешения будут замаскированы в процессе создания каталога. Если umask равен 027 (восьмеричное представление), то он будет запрещать доступ на запись для группы-владельца и полностью запрещать доступ для остальных пользователей. $ umask 027 $ mkdir dir $ ls -dl dir drwxr-x--- . agruen suse . dir Первый символ в выводе команды ls характеризует тип файла (d для каталога). Запись “rwxr-x---” характеризует разрешения на доступ к новому каталогу: чтение, запись и выполнение для владельца и чтение и выполнение для группы-владельца. Многоточие в данном примере соответствует тексту, которые не относится к данной теме, и поэтому он был убран с целью более легкого восприятия примеров. Эти базовые разрешения имеют свой эквивалент в ACL. Просмотреть ACL можно при помощи команды getfacl. $ getfacl dir # file: dir # owner: agruen # group: suse user::rwx group::r-x other::--- Первые три строки вывода команды getfacl содержат имя файла, владельца и группу-владельца файла в виде комментариев. Каждая из следующих строк содержит ACE одного из трех классов пользователей: владельца, группы и остальных. Следующий пример добавляет права на чтение, запись и выполнение для пользователя Joe к существующим разрешениям. Для этого используется параметр –m (modify, изменить) команды setfacl(1). Вывод итогового ACL будет опять осуществляться командой getfacl(1). Опция –omit-header (пропуск заголовка) команды getfacl(1) не показывает первые три строки в выводе, которые содержат имя файла, владельца и группу-владельца файла и укорачивает вывод команды, как это показано ниже. $ setfacl -m user:joe:rwx dir $ getfacl --omit-header dir user::rwx
user:joe:rwx group::r-x mask::rwx other::--- В ACL были добавлены две дополнительные записи: одна для пользователя Joe, другая – запись-маска. Запись-маска автоматически создается, когда это необходимо. Ее разрешения являются объединением разрешений всех записей класса групп, и, таким образом, она не маскирует никакие разрешения.
Теперь запись-маска будет определять разрешения для класса групп. Вывод команды ls изменится и будет выглядеть так, как это показано ниже. $ ls -dl dir drwxrwx---+ . agruen suse . dir Дополнительный символ “+” добавляется ко всем файлам, для которых определен расширенный ACL. На первый взгляд этот дополнительный символ кажется вовсе ненужным, но на самом деле POSIX.1 назначает этому символу необязательный флаг альтернативного метода доступа, который по-умолчанию устанавливается пустым, если не используются никаких альтернативных методов доступа. Таким образом, этот символ указывает на то, что если определен альтернативный метод доступа, то в процессе доступа к такому файлу будут использоваться именно он. Разрешения класса групп содержат разрешение на запись. Традиционно такие биты файловых разрешений показывают возможность записи для группы-владельца. В случае, если определен ACL, эффективными разрешениями для группы-владельца будет пересечение разрешений группы владельца и записи-маски. Эффективные разрешения для группы-владельца в данном примере по прежнему “r-x”, т.е после создания дополнительных ACE командой setfacl(1) они не изменились. Разрешения класса групп могут быть изменены при помощи команд setfacl(1) или chmod(1). Если не определена запись-маска, chmod(1) изменит разрешения записи группы-владельца традиционно. В следующем примере командой chmod(1) запретим доступ на запись для класса групп и посмотрим, что изменилось. $ chmod g-w dir $ ls -dl dir drwxr-x---+ . agruen suse . dir $ getfacl --omit-header dir user::rwx user:joe:rwx #effective:r-x group::r-x mask::r-x other::--- Как показано выше, если ACE содержит разрешения, которые превышают разрешения записи-маски, команда getfacl добавляет комментарий к этой ACE, который показывает эффективный набор разрешений, гарантированный этой ACE. Если бы ACE группы-владельца содержала бы разрешения на запись, то к ней был бы добавлен такой же комментарий. Посмотрим теперь, что изменится, если вернуть разрешения на запись для класса групп. $ chmod g+w dir $ ls -dl dir drwxrwx---+ . agruen suse . dir $ getfacl --omit-header dir user::rwx user:joe:rwx group::r-x mask::rwx other::--- После добавления разрешения на запись для класса групп, ACL вновь определяет те же разрешения на доступ, как и до запрещения записи для класса групп. Команда chmod(1) производит неразрушительный эффект на ACL. Это особенность является чрезвычайно важной для POSIX.1e ACL. 3.2.3 Пример ACL по-умолчанию В следующем примере добавим ACL по-умолчанию к катологу и посмотрим, что изменилось в выводе команды getfacl. $ setfacl -d -m group:toolies:r-x dir $ getfacl --omit-header dir user::rwx user:joe:rwx group::r-x mask::rwx other::--- default:user::rwx default:group::r-x default:group:toolies:r-x default:mask::r-x default:other::--- Текстовое представление ACL по-умолчанию выгладит также, как и ACL доступа, за исключением того, что перед ACE по-умолчанию добавляется префикс “default:”. Этот формат вывода является расширением POSIX.1e, которое применяется в Solaris и Linux. Строгое соответствие POSIX.2c проявляется только для ACL доступа. Посмотреть ACL по-умолчанию можно используя опцию –d команды getfacl(1). В данном примере была указана ACE для группы toolies в команде setfacl(1). Остальные ACE, необходимые для полноценного ACL, автоматически скопировались из ACL доступа. Это специфическая особенность Linux; в других операционных системах может потребоваться конкретное указание всех необходимых записей. ACL по-умолчанию не содержит ACE для пользователя Joe, следовательно Joe не будет иметь прав на доступ к вновь создаваемым файлам в этом каталоге (за исключением тех прав, которые гарантируются членством в группе или записью для остальных). Подкаталог наследует ACL как это показано ниже. Если не указано иначе, команда mkdir использует значение 0777 (0rwxrwxrwx) в качестве параметра режима доступа для системного вызова на создание нового каталога. В итоге и ACL доступа, и ACL по-умолчанию нового подкаталога будут содержать одинаковые ACE. $ mkdir dir/subdir $ getfacl --omit-header dir/subdir user::rwx group::r-x group:toolies:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:toolies:r-x default:mask::r-x default:other::--- Файлы, создаваемые внутри каталога, наследуют его разрешения так, как это показано ниже. Команда touch использует значение 0666 (0rw-rw-rw-) в качестве параметра режима доступа для системного вызова на создание нового файла. Все разрешения, которые отсутствуют в параметре режима доступа, удаляются из соответствующих ACE. То же самое происходило и в предыдущем примере, но это не оказывало никакого эффекта, поскольку значение 0777 соответствует параметру режима доступа с полным набором разрешений. $ touch dir/file $ ls -l dir/file -rw-r-----+ . agruen suse . dir/file $ getfacl --omit-header dir/file user::rw- group::r-x #effective:r-- group:toolies:r-x #effective:r-- mask::r-- other::--- Никакие разрешения не были удалены из ACE класса групп. Вместо этого они были замаскированы и, таким образом, стали неэффективными. Это гарантирует, что традиционные инструменты, такие как компиляторы, будут правильно взаимодействовать с ACL. Они могут создавать файлы с ограниченными разрешениями и позже добавлять к ним права на выполнение. Механизм маски позволяет гарантировать необходимые права на доступ только для правильных пользователей и групп. 3.2.4 Расширенные атрибуты В этом параграфе буте детально рассмотрена реализация ACL в Linux. ACL представляют собой информационные блоки переменной длины, ассоциированные с объектами файловой системы. В каждой операционной существуют определенные правила хранения ACL для конкретной файловой системы, как например в Solaris для файловой системы UFS [13]. Каждый узел inode в файловой системе UFS имеет поле i_shadow. Если узел inode имеет ACL, то это поле указывает на теневой inode. В файловой системе теневые inode используются как обычные файлы. Каждый теневой inode хранит ACL в своем блоке данных. Несколько файлов с одним и тем же ACL могут ссылаться на один и тот же теневой inode. Так как многие системные и пользовательские расширения в дополнение к ACL выигрывают от возможности ассоциировать блоки данных с файлами, Linux и большинство других UNIX-подобных операционных систем реализуют более общий механизм расширенных атрибутов (Extended Attributes, EAs). В таких системах ACL реализовывается в виде EAs.
EAs представляют собой пары имени и значения, которые постоянно ассоциированы с объектами файловой системы, схожим образом с переменными окружения процесса. Системные вызовы EA используются как интерфейс взаимодействия между системными и пользовательскими именами и значениями атрибутов между пользовательскими и системными адресными пространствами. Страница attr(5) руководства Linux содержит более подробное описание EAs в Linux. Работа Роберта Ватсона (Robert Watson) о поддержке инфраструктуры расширений безопасности в FreeBSD содержит сравнение различных реализаций EA на различных системах [25].
Другие операционные системы, такие как Sun Solaris, Apple MacOS и Microsoft Windows, позволяют нескольким потокам (или процессам) информации быть ассоциированы с одним единственным файлом. Эти потоки поддерживают обычную файловую семантику. После получения адреса потока, становится возможным получить доступ к содержимому потока, используя обычные файловые операции, такие как чтение и запись. Ошибочно в Solaris эти потоки тоже называются расширенными атрибутами. В Linux и некоторых других UNIX-подобных системах EAs не имеют ничего общего с этими потоками. Более ограниченный интерфейс EA предоставляет несколько преимуществ. Они более легки в реализации, операции EA иерархично атомарные и интерфейс не страдает от нагрузок от получения и освобождения адреса файла. Для наиболее часто используемых объектов, таких как ACL, эффективность особенно важна. На уровне файловой системы очевидной реализацией EAs является создание дополнительного каталога для каждого объекта файловой системы, который имеет EAs и создание одного файла для каждого расширенного атрибута, который имеет имя и содержит значение. Так как в большинстве файловых систем выделение дополнительного каталога и одного или нескольких файлов требует несколько дисковых блоков, такая простая реализация приведет к большим потерям дискового пространства, и она не будет работать достаточно хорошо из-за того, что будет требоваться определенное время для доступа к этим дисковым блокам. Поэтому большинство файловых систем используют другие механизмы хранения EAs. 3.2.4.1 Ext2 и Ext3 Как описано в исходном коде ядра Linux, каждый inode содержит поле i_file_acl по историческим причинам. Если это поле ненулевое, оно содержит номер блока файловой системы, в котором хранится EAs, ассоциированные с этим inode. Все EAs определенного inode должны располагаться в одном EA блоке. Для увеличения эффективности, несколько inode с идентичными наборами EAs могут указывать на один и тот же EA блок. Количество inode, ссылающихся на EA блок, отслеживается счетчиком ссылок в EA блоке. Разделение EA блоков прозрачно для пользователя: Ext3 хранит список блоков, к которым недавно был предоставлен доступ, и таблицу с двумя индексами (реализованную в виде хэш таблиц дважды связанных листов). Один индекс характеризует номер блока, другой – контрольную сумму содержимого блока. Блоки, содержащие одинаковые данные, с которым должен быть ассоциирован новый inode, используются заново до тех пор, пока счетчик ссылок блока не достигнет верхнего предела величиной 1024. Это уменьшает возможное повреждение, которое может быть вызвано сбоем одного блока. Когда inode ссылается на разделяемый EA блок и меняется значение EAs этого inode, используется механизм copy-on-write до тех пор, пока другой кэшированный EA блок не будет содержать такого же набора атрибутов, в этом случае будет использоваться этот блок. Текущая реализация требует, чтобы все EAs конкретного inode располагались в одном дисковом блоке, который имеет размер 1, 2 или 4 Кб. Это ограничение также определяет максимальный размер отдельных атрибутов. Если наборы EAs уникальны внутри inode, нет никаких разделений EA блоков и время на проверку потенциального разделения потрачено зря. Если каждый inode имеет уникальный набор EAs, каждый из этих наборов будет сохранен в отдельном дисковом блоке, что приведет к излишним потерям в дисковом пространстве. Крайний случай возникает тогда, когда приложения требуют хранения уникальных EAs для каждого inode. К счастью в реальной ситуации в наиболее общем случае механизм разделения EA достаточно эффективен. Были предложены альтернативные способы с меньшим числом ограничений [5], но оказалось, что они довольно сложны в конкретной реализации. На данный момент для данной схемы не существует никаких альтернатив. 3.2.4.2 JFS JFS хранит все EAs конкретного inode в последовательности блоков файловой системы [3]. Пары имен и значений расширенного атрибута хранятся последовательно в этой последовательности. Если EAs в совокупности достаточно малы, то они хранятся целиком внутри inode, к которому они принадлежат. JFS не реализует механизма разделения EA. В ней нет ограничений на один блок как в Ext2 и Ext3. Размер отдельного атрибута ограничивается размером 64 Кб. 3.2.4.3 XFS Из всех файловых систем, поддерживаемых в настоящее время в Linux, XFS использует наиболее тщательно проработанную схему хранения расширенных атрибутов [1]. Маленькие наборы EAs хранятся прямо в inode, наборы среднего размера хранятся в листовых блоках B+ деревьев, а большие наборы EAs хранятся в полных B+ деревьях. Это находит свое выражение в производительности хранения очень большого количества EAs. XFS обладает настраиваемым размером inode, который задается в процессе создания файловой системы. Минимальный размер равен 256 байтам, именно такой размер и устанавливается по-умолчанию. Максимальный размер равен половине размера блока файловой системы. В минимальном случае, inode слишком малы для того, чтобы содержать ACL, и, следовательно, ACL будут храниться отдельно. Если увеличить размер inode, ACL сможет храниться в inode. Так как inode и ACL часто используются за короткий промежуток времени, то в результате такой организации будут быстрее производиться проверки на доступ, но зато это потребует большего дискового пространства. XFS не использует механизма разделения EA. Размер отдельных атрибутов ограничен 64 Кб. 3.2.4.4 ReiserFS ReiserFS поддерживает механизм поглощения хвостов файлов. Это означает, что несколько файлов могут разделять один и тот же дисковый блок для хранения своих данных. Это делает файловую систему очень эффективной для хранения большого числа маленьких файлов. Существует одно потенциальное препятствие: поглощение хвоста может требовать существенных временных ресурсов процессора. Так как ReiserFS хороша для хранения маленьких файлов, EAs могут напрямую использовать этот механизм. Для каждого файла, который имеет EAs, в специальном каталоге создается каталог с именем, которое определяется уникальным идентификатором inode. Специальный каталог обычно спрятан от пространства имен файловой системы. Внутри специфического для данного inode каталога, каждый EA храниться в виде отдельного файла. Имя файла совпадает с именем атрибута. Содержимое файла – это значение атрибута. В настоящее время ReiserFS не использует механизм разделения атрибутов, но такое расширение возможно будет реализовано в будущем. Разделение может также быть реализовано на по-атрибутной основе, это будет наиболее эффективным и гибким решением. Размер отдельного атрибута ограничивается 64 Кб.
3.2.5 Производительность EA и ACL Так как ACL предоставляют более продуманный и проработанный механизм управления доступом, они используются всегда, когда необходимо принятие решения о правах доступа к объектам файловой системы. Интересно сравнить время, которое необходимо потратить на принятие такого решения с ACL и без него.
Измерения были проведены на ПК с операционной системой SuSE Linux 8.2 с ядром SuSE 2.4.20. В ПК установлены процессор AMD Athlon с тактовой частотой 1.1 ГГц и оперативная память, объемом 512 Мб. Тестирование проводилось на жестком диске IBM Ultra ATA 100 объемом 30 Гб со скоростью вращения цилиндров 7200 об/м, среднее время посиска 9.8 мс, размер дискового кэша 2 Мб. Файловые системы Ext2, Ext3, ReiserFS и JFS создавались на разделе размером 8 Гб с параметрами по-умолчанию. В случае XFS для сравнения EAs, которые хранятся в inode, и EAs, которые хранятся вне inode, были созданы файловые системы XFS с размерами inode 512 байта и 256 байт. Эти файловые системы названы XFS-512 и XFS-256 соответственно. Таблица 5 показывает результаты тестирования времени, затраченного на начальную проверку прав доступа к файлу с ACL и без ACL после перезагрузки системы. Для того, чтобы исключить время, потраченное на загрузку файлового inode в кэш, вызывался системный вызов stat перед каждой проверкой прав доступа. Время, потраченное на этот вызов не показано. Первое использование ACL доступа файла может потребовать одного или более прямых доступов к диску, которые во много раз медленнее доступа к диску через кэш. Настоящее время этих доступов к диску довольно широко зависит от скорости вращения цилиндров и относительного расположения блоков, к которым предоставляется доступ. Функция, используемая для измерения времени имеет порядок аппроксимации в микросекунду. В случае ACL файл, к которому проверялись права доступа, имел ACL с пятью ACE. Таблица 5: Производительность ACL в SuSE 8.2 Без ACL, мкс С ACL, мкс Ext2 9 1743 Ext3 10 3804 ReiserFS 9 6165 XFS-256 14 7531 XFS-512 14 14 JFS 13 13 XFS с размером inode 512 байт (или больше) и JFS хранят ACL прямо в inode. Поэтому в этом случае нет необходимости в дополнительных доступах к диску для получения ACL. После первого использования ACL вся информация полностью кэшируется. В каждом тесте одна и та же операция повторялась много раз и усреднялось время, потраченное на проделывания этих операций. Команда ls –l показывает в своем выводе имеет ли файл расширенный ACL. Внутренне она использует функцию acl_extended_file библиотеки libacl. Эта функция почти так же быстра, как и системный вызов stat, который команда ls –l также вызывает для каждого файла, так что итоговые временные расходы малы. Таблицы 6 и 7 показывают включенные временные расходы на копирование файлов из одной файловой системы в другую. Все копируемые файлы имеют ACL, но не имеют дополнительных EAs. Тесты показывают время, потраченное на операции, начиная с команды cp и заканчивая командой sync, которая запускалась сразу же после команды cp. Команда sync гарантирует, что файлы будут немедленно записаны. В первом случае использовалась версия cp, которая не имеет поддержки EAs и ACL. Во втором случае использовалась версия cp, которая поддерживала и EAs и ACL. В обоих тестах файловая система-источник оставалась неизменной, в то время как файловая система-приемник менялась. В примере для теста в таблице 6 размеры достаточно мал для всех файлов, чтобы уместить их в главную память. Время, потраченное на первое чтение файлов в память, не учитывалось. Эти тесты повторялись 5 раз. Результаты содержат среднее и стандартное распределение. В примере для теста, показанного в таблице 7, размеры файлов больше чем размер главной памяти и размер системного файлового журнала. Эти тесты проводились единожды. Таблица 6: Копирование файлов из памяти в файловую систему (11351 файлов, 608 каталогов, итоговый размер файлов = 137 Мб) Файловая система Без С Накладные расходы,% EAs, с ACLs, с EAs, с ACLs, с Ext2 18.3 0.2 18.8 0.2 3 Ext3 22.0 2.4 22.7 0.5 3 ReiserFS 9.0 0.1 12.8 0.1 42 XFS-256 19.0 0.2 34.1 0.2 80 XFS-512 20.1 0.4 21.4 0.2 7 JFS 38.2 0.6 36.5 0.2 4 Таблица 7: Копирование файлов между файловыми системами (96183 файлов, 6323 каталогов, итоговый размер файлов = 2.8 Гб) Файловая система Без EAs и ACL, с С ACL, с Накладные расходы, % Ext2 595 578 3 Ext3 613 623 2 ReiserFS 518 538 4 XFS-256 547 641 17 XFS-512 549 566 3 JFS 654 590 11 Важно отметить, что оба теста проводились при излишних ACL, что является самым худшим вариантом. Временные расходы в реальных жизненных ситуациях должны быть намного меньше. Необходимо также отметить, что временные задержки в случае ACL сильно менялись в зависимости от поддерживаемых файловых систем. Эти различия больше проявляются при маленьких нагрузках на систему ввода-вывода и становятся менее очевидными при больших загрузках системы ввода-вывода. Для ACL реализации Ext2 и Ext3 имеют небольшие временные задержки. Расходы на EAs в ReiserFS достаточно высоки. Эту ситуацию можно улучшить, если реализовать механизм разделения EAs. Для XFS имеет большое значение увеличения размера inode с тем, чтобы ACL уменьшался прямо в нем.
3.2.6 Реализации ACL Интересным с точки зрения реализации является то, каким образом ACL передается между пользовательским пространством и ядром, и внутри ядра между виртуальной файловой системой (VFS) и низкоуровневым слоем файловой системы. FreeBSD, Solaris, Irix и HP-UX имеют отдельные системные вызовы ACL [21,9,23,17]. В Linux нет системных вызовов ACL. Вместо этого, ACL передаются между ядром и пользовательским пространством в виде EAs. Это уменьшает число системных интерфейсов, но с тем же числом конечных операций. В то время как системные вызовы ACL предоставляют более явный системный интерфейс, интерфейс EA легче адаптировать к будущим требованиям, таким как нецифровые идентификаторы пользователей и групп в ACE. Рациональность в использовании отдельных системных вызовов ACL в FreeBSD обусловлена тем, что некоторые файловые системы поддерживают EAs, но не поддерживают ACL, а некоторые файловые системы поддерживают ACL, но не поддерживают EAs, и, следовательно, EAs воспринимаются как двоичные данные в чистом виде. EAs и ACL становятся родственными только внутри файловой системы [24,26]. Рациональность реализации Linux заключается в предоставлении доступа ко всем метаданным объекта файловой системы через единый интерфейс. Имена атрибутов “system.posix_acl_access” и “system.posix_acl_default” используются для ACL доступа и ACL по-умолчанию файла соответственно. Значения атрибута имеют канонический и архитектурно-независимый двоичный формат. Хотя возможна манипуляция ACL напрямую как EAs, на уровне приложения это не всегда так: так как системные вызовы EA специфичны для Linux, такие приложения не будут переносимыми (независимыми от ОС). Другие операционные системы поддерживают похожие механизмы EA, но с различными интерфейсами системных вызовов. Приложения, которые стремятся к использованию POSIX.1 ACL в переносимом смысле, должны использовать библиотеку libacl, которая реализует ACL-специфические функции соответственно драфту 17 POSIX.1e. Доступ к ACL доступа объекта файловой системы осуществляется перед каждым решением на доступ, которое включает этот объект. Проверка доступа осуществляется на всем пути от исходного пространства пользователя до файла. Для того, чтобы избежать частого просмотра атрибутов ACL и конвертирования из архитектурно-независимого представления атрибутов в архитектурно-специфическое, реализации Ext2, Ext3, JFS и ReiserFS используют кэширующие механизмы, которые используют либо кэш страницы, либо буферный кэш, либо их вместе. XFS не использует этот дополнительный уровень кэширования. Большинство UNIX-подобных систем, поддерживающих ACL, ограничивают максимальное число возможных ACE каким то числом. Таблица 7 показывает эти ограничения для Linux. Таблица 7: Максимальное количесво поддерживаемых ACE Файловая система Максимум ACE XFS 25 Ext2, Ext3 32 ReiserFS, JFS 8191 ACL с большим числом ACE более сложны в обслуживании. Использование большого числа ACE обычно указывает на плохое построение приложения. В большинстве таких случаев более грамотное использование групп будет более лучшим решением, чем раздутие ACL. Реализации ACL в файловых системах ReiserFS и JFS не накладывают ограничений на максимальное число ACE, и, таким образом, этот предел ограничен лишь максимальным размером EA значений. В настоящее время размер EA ограничивается 64 Кб, или 8191 ACE, что является весьма большим значениям для практической реализации: кроме того, это довольно непрактично. Время, потраченное на проверку прав доступа в таком большом ACL, может оказаться довольно большим. 3.2.7 Совместимость Важным аспектом в ознакомлении с новыми особенностями файловой системы является то, каким образом системы модернизируются, и то, как ведут себя системы, не поддерживающие новые особенности. Форматы файловых систем развиваются медленно. Ожидается, что файловые системы будут продолжать работать со старыми версиями ядра. В некоторых ситуациях, как например загрузка с множественными режимами и параметрами запуска или загрузка со спасательной системы, может быть необходимым или более предпочтительным использовать ядро, которое не поддерживает EA. Все файловые системы, поддерживающие ACL в Linux, либо наследственно осведомлены о EAs, либо модернизируются для поддержки EAs автоматически без вмешательства пользователя. В зависимости от файловой системы это происходит либо в момент монтирования файловой системы, либо в момент первого запроса на использование EAs. Во всех файловых системах, рассматриваемых в этой главе при использовании ядра, которое не поддерживает EAs для файловой системы, которая их поддерживает, EA будут игнорироваться. В ReiserFS, ядра, знающие о EA, прячут системный каталог, который содержит EAs, а при использовании ядер, не осведомленных о EAs, этот каталог становится видимым. Он до сих пор защищен от обычных пользователей через файловые ограничения. Работа с файловыми системами, поддерживающими EA на ядрах, не поддерживающих EA, будет приводить к ряду неприятностей, когда будут удаляться файлы, имеющие EAs. В этом случае EAs не будут удалены, и это скажется в излишнем использовании дискового пространства. По крайней мере в Ext2 и Ext3 такие EAs, которые остались без своих объектов, могут быть удалены позже при помощи запуска проверки файловой системы. Ядра, не знающие об ACL, используют традиционные биты файловых разрешений и не способны проверять разрешения, основываясь на определенных ACL. Алгоритм ACL в таких системах работать не будет. 3.3 ACL в Solaris 3.3.1 Более гибкая система безопасности По мере распространения Solaris в коммерческих вычислительных комплексах появляется необходимость в использовании более гибких схем обеспечения безопасности доступа к файловым системам. Стандартно права доступа к файлу или каталогу определяются битами режима файла с помощью команды chmod(1). Файловый режим позволяет разрешать или запрещать права read, write и execute для трех различных типов пользователей - владельца файла (user), членов той же группы, что и владелец (group), и всех остальных пользователей системы (other). Такая схема не обеспечивает особой гибкости, поскольку не позволяет указать конкретный набор прав для данного пользователя или группы.
Биты файлового режима находятся в inode (в поле i_mode) файла, а значение по умолчанию для вновь создаваемых файлов определяется значением параметра umask пользователя, причем этот режим может быть изменен владельцем файла с помощью команды chmod(1) (владелец файла может быть изменен командой chown(1)). Там где этого достаточно, безопасность файловой системы в Solaris можно и сегодня поддерживать указанным способом. Однако для систем, требующих большей гибкости и контроля в управлении безопасностью, существуют ACL, которые были впервые введены в Solaris 2.5.1.
ACL позволяет владельцу файла управлять правами на файлы и каталоги в UFS (файловая система по умолчанию в Solaris) для отдельных пользователей и групп. Кроме того, владелец файла может определять набор прав по умолчанию в каталоге, так что все файлы, создаваемые в этом каталоге, получают одинаковый набор ACL. Поддержка ACL существует сегодня в Solaris для следующих типов файловых систем: UFS, NFS (версии 2 и 3), CacheFS и LOFS. Другие типы файловых систем в Solaris ничего не знают об ACL, и следовательно, не могут осуществлять защиту в соответствии с ACL файла. Кроме того, ACL могут применяться только к каталогам, нормальным файлам, FIFOs и символическим ссылкам (symbolic links). 3.3.2 Формат ACL Формат для файлового ACL состоит из двух или трех колонок, разделенных двоеточием: entry_type:[uid|gid]:perms Первая колонка, entry_type, определяет ACL для пользователя, группы, других или маску (ACL mask). Вторая колонка - это (возможно) пользовательский ID (UID) или имя пользователя, или групповой ID (GID) или имя группы. Для типов other или mask, эта колонка неприменима и потому не требуется. Третья колонка предназначена для файловых разрешений. Файловые разрешения принимают форму либо обычных rwx (read/write/execute), либо числовую форму в восьмеричной системе (например, 7 для rwx, 4 для r--, 6 для rw-, и т.д.), что полностью эквивалентно формату в chmod(1). Внутреннее представление в виде структуры данных выглядит так (из /usr/include/sys/acl.h): typedef struct acl { int a_type; /* тип записи */ uid_t a_id; /* UID | GID */ o_mode_t a_perm; /* разрешения */ } aclent_t; Каждое поле в указанной структуре соответствует частичному полю ACL, описанным выше. Когда идентификатор пользователя (или UID) отсутствует, и поле идентификатора группы (или GID) пусто, то применяются традиционные файловые права Solaris (это будет показано в примере ниже). Пользователи устанавливают, модифицируют и удаляют ACL с помощью команды setfacl(1), и проверяют файловые ACL с помощью команды getfacl(1). 3.3.3 Примеры работы с ACL Короткий пример ниже демонстрирует использование файловых ACL. 1 sunsys> ls -l file1 2 -rwxr-xr-- 1 joe staff 130 May 25 22:13 file1 3 sunsys> chmod 000 file1 4 sunsys> ls -l file1 5 ---------- 1 joe staff 130 May 25 22:13 file1 6 sunsys> setfacl -s user::rw-,group::r--,other:r-- file1 7 sunsys> ls -l file1 8 -rw-r--r-- 1 joe staff 130 May 25 22:13 file1 9 sunsys> getfacl file1 10 # file: file1 11 # owner: joe 12 # group: staff 13 user::rw- 14 group::r-- #effective:r-- 15 mask:r-- 16 other:r-- 17 sunsys> setfacl -m user:moe:rw- file1 18 sunsys> ls -l file1 19 -rw-r--r--+ 1 joe staff 130 May 25 22:13 file1 20 sunsys> getfacl file1 21 # file: file1 22 # owner: joe 23 # group: staff 24 user::rw- 25 user:moe:rw- #effective:r-- 26 group::r-- #effective:r-- 27 mask:r-- 28 other:r— Строка 6 демонстрирует команду setfacl(1) с опцией -s, которая означает установку ACL. Команда setfacl(1) в строке 6 не определяет специальных прав для конретных пользователей или групп. Это в основном эквивалентно исполнению команды chmod 644 над тем же файлом. С помощью команды getfacl(1) (строка 9) отображаются файловые права в формате ACL. Фактически в этот момент для этого файла ACL не определен. Ядро Solaris отслеживает установку ACL, и для простых случаев, когда команда setfacl(1) просто устанавливает традиционные файловые права для владельца, группы-владельца и остальных, реальный ACL для файла не создается. Ядро устанавливает права, определенные командой setfacl(1) в соответствующем поле в inode. В строке 17 устанавливаются права на чтение и запись для пользователя Moe, используя опцию –m (modify, изменить) с командой setfacl(1). Теперь при запуске команды getfacl(1) (строка 20), мы видим добавление ACE для пользователя Moe в ACL. Есть несколько важных моментов по поводу поведения ACL и правил старшинства. Этот пример показывает ACL с маской “r--”. Маска ACL определяет максимальные права, выделенные всем, кроме владельца файла; в данном примере все, кроме владельца файла имеют права только на чтение. Однако, в ACL определены права на чтение и запись для пользователя Moe. Так что же случится, если пользователь Moe попытается записать в файл - что окажется главнее - его специальные права или маска ACL? Ответ заключается в том, что “победит” маска ACL. Вот еще один короткий пример: 1 sunsys> getfacl file1 2 # file: file1 3 # owner: joe 4 # group: staff 5 user::rw- 6 user:moe:rw- #effective:r-- 7 group::r-- #effective:r-- 8 mask:r-- 9 other:r-- 10 sunsys> su moe 11 Password: 12 $ id 13 uid=2001(moe) gid=22(stooges) 14 $ echo "write test" >> file1 15 file1: cannot create 16 $ exit 17 sunsys> setfacl -m m:rw- file1 18 sunsys> getfacl file1 19 # file: file1 20 # owner: joe 21 # group: staff 22 user::rw- 23 user:moe:rw- #effective:rw- 24 group::r-- #effective:r-- 25 mask:rw- 26 other:r-- 27 sunsys> su moe 28 Password: 29 $ echo "write test" >> file1 30 $ exit 31 sunsys> Здесь не были рассмотрены, конечно, все варианты установки прав ACL. Более подробная информация содержится в страницах руководства setfacl(1) и getfacl(1), а также в документации Solaris. Для программных вызовов ACL существуют acl(2) и facl(2), а также библиотечные функции aclcheck(3) и aclsort(3). 3.4 NFS и ACL Полная поддержка ACL для NFS требует двух составляющих: во-первых, механизма, который бы позволял принимать все решения относительно прав доступа так, как этого требует ACL; во-вторых, расширений протокола NFS для использования ACL на смонтированных удаленных файловых системах. Протокол NFS производит кэширование на стороне клиента для увеличения эффективности. Во второй версии протокола решения, для кого должен предоставляется доступ на чтение локальных данных из кэша, осуществляется на стороне клиента. Принятие этих решений основывается на предположении, что файловых битов режима доступа и идентификаторов владельца и группы-владельца достаточно для принятия такого решения. Это предположение очевидно ошибочно, если на сервере используется расширенная схема разрешений, такая как POSIX ACL.
Так как клиенты протокола NFSv2 принимают некоторые решения на доступ локально, они будут неправильно гарантировать доступ на чтение файла и содержимого каталога, кэшированных на клиенте, для пользователей, которые входят в группу-владелец в двух случаях. Первый, если разрешения класса групп включают право на чтение, но группа-владелец такого права не имеет. Второй, если группа-владелец имеет разрешение на чтение, но существует ACE именного пользователя для данного пользователя, в которой отсутствует разрешение на чтение. Обе ситуации довольно редки. Существуют решения, которые уменьшают разрешения на стороне сервера так, чтобы клиенты видели только необходимый им реальный набор разрешений [10,7]. Для пользователей, не входящих в группу-владелец, такие аномалии не возникают.
Существуют два способа разрешения данной проблемы. Первый заключается в расширении алгоритма проверки прав доступа, используемом на стороне клиента. Второй заключается в передаче ответственности за принятие решений на доступ на сервер и возможно кэширование этих решений на определенный промежуток времени на клиенте. Первый способ возможно будет больше подходить в случае большого количества пользователей на стороне клиента, при условии, что и сервер и все клиенты договорятся об используемом алгоритме проверки прав доступа. К несчастью, этот способ не удается реализовать, если серверы используют различные схемы разрешений. Версия 3 протокола NFS определяет новый удаленный вызов процедур (RPC) ACCESS для передачи полномочий на принятие решений относительно прав доступа на сервер. Этот RPC схож с системным вызовом доступа. Ожидается, что клиенты NFSv3 будут использовать этот RPC для определения кому должен быть предоставлен доступ к кэшированному содержимому. Протокол NFSv3, к несчастью, не определяет механизма передачи ACL. Как следствие, различные изготовители реализовали правильные расширения протокола, которые не совместимы друг с другом. Реализованное в Solaris расширение протокола NFS ACL поддерживает только ACL. Более общая реализация протокола в Irix поддерживает EAs и манипулирует ACL как специальными EAs. Протокол NFSv4 определяет структуру и семантику своих собственных ACL наряду с RPC для передачи их между клиентом и сервером. ACL NFSv4 похожи на ACL Microsoft Windows [14]. К несчастью, дизайнеры NFSv4 в основном проигнорировали существование POSIX ACL, и, таким образом, ACL NFSv4 не совместимы с POSIX ACL. Мариус Амодт Эриксен (Marius Aamodt Eriksen) описывает одностороннее соответствие между POSIX ACL и ACL NFSv4 [6], но это соответствие непрактично. Одним из центральных понятий в POSIX ACL, которое необходимо для гарантии совместимости с приложениями POSIX.1, является запись-маска. Модель ACL NFSv4 может быть расширена понятием маски. И хотя это позволило бы сильно улучшить взаимодействие с POSIX ACL, предложения расширить спецификацию NFSv4 до сих пор отклонялись. Частичная поддержка NFSv3 была добавлена в ядра Linux версии 2.2. ACCESS RPC был добавлен в NFS демон ядра в версии 2.2.18, но клиенты NFS корректно используют ACCESS RPC только в ядрах версии 2.5. Патч для более старых версий ядра существует с версии 2.4.19. Так как ACCESS RPC может приводить к значительным издержкам в сети даже для файловых систем, о которых известно, что в них нет ACL, клиенты Linux NFSv3 могут монтировать файловые системы с опцией noacl. В этом случае клиент не будет использовать ни ACCESS RPC, ни GETACL RPC, ни SETACL RPC. Для того, чтобы гарантировать, что никакие ACL не будут установлены на сервере, файловые системы Ext2, Ext3, JFS и ReiserFS могут быть смонтированными на сервере без поддержки ACL, если опустить опцию монтирования acl. С 3 марта 2003 года реализация протокола NFS ACL компании Sun для Linux доступна на сайте http://acl.bestbits.at/. Был выбран протокол NFS ACL, так как он достаточно прост и он достаточно хорошо поддерживает ACL драфта 17 POSIX 1003.1e. В Solaris ACL основаны на более ранних драфтах POSIX 1003.1e, и поэтому существуют различия в способах обработки маски для ACL только с четырьмя записями. Это довольно частный случай и возникает он довольно редко, так что семантические отличия могут быть не настолько очевидными. 3.5 Samba и ACL Microsoft Windows поддерживает ACL в своей файловой системе NTFS и в своем протоколе CIFS [20], который формально известен как протокол SMB. CIFS используется для предоставления доступа к файловым сервисам и сервису печати по сети. Samba является Open Source реализацией CIFS. Samba используется для предоставления доступа к файловым сервисам и сервису печати для пользователей Windows в сети. Samba позволяет манипулировать POSIX ACL из Windows. Эта особенность добавляет новый аспект во взаимном общении UNIX и Windows. Модель ACL в Windows отличается от модели POSIX ACL по ряду причин, поэтому оказывается невозможным предоставление полной интеграции. Наиболее значительное различие между этими двумя моделями состоит в следующем: ACL в Windows поддерживают около десяти различных разрешений для каждой записи в ACL, включая такие как “дописать”, “удалить”, “изменить разрешения”, “присвоить владение”, “изменить владельца”. Текущие реализации POSIX ACL поддерживают только разрешения на чтение, запись и выполнение. В алгоритме проверки разрешений POSIX гарантируется, что процесс получит доступ согласно наиболее значащей ACE, определяющей разрешения. Таким образом, более детальные разрешения конструируются добавлением более близко подходящих ACE по необходимости. В модели Windows ACL имеют накопленный характер, то есть разрешения которые будут гарантированы в любом случае могут быть запрещены только запрещающими ACE. POSIX ACL не поддерживают запрещающих ACE. Запретить доступ для пользователя можно созданием специального ACE именного пользователя, в котором будут отсутствовать разрешения. Иерархическая модель ACL Windows была похожа на модель POSIX ACL. Начиная с Windows 2000 Microsoft использует динамическую иерархическую модель, которая предоставляет разрешения распространяясь вниз по иерархии каталогов, когда изменяются разрешения корневого (родительского) каталога. POSIX ACL наследуются только в момент создания файла. В модели POSIX ACL доступа и ACL по-умолчанию являются ортогональными понятиями. В модели ACL Windows несколько различных флагов в каждой ACE управляют тем, как и когда запись наследуется контейнерами и объектами, не являющимися контейнерами. ACL в Windows имеют различные концепции определения разрешений для владельца и группы-владельца. Понятие группы-владельца было введено только с Windows 2000. Это приводит к различным результатам смены владельца. POSIX ACL имеют записи для владельца и группы-владельца как в ACL доступа, так и в ACL по-умолчанию. В момент проверки прав доступа к объекту эти записи ассоциируются с текущим владельцем и группой-владельцем этого объекта. ACL в Windows поддерживают две псевдогруппы: владелец-создатель и группа-создатель, которые служат похожим целям наследования разрешений, но эти псевдогруппы не действительны для записей, определяющих доступ. Когда объект наследует разрешения, эти абстрактные записи конвертируются в записи для конкретного пользователя и группы.
Несмотря на семантическое несоответствие между этими двумя системами ACL, POSIX ACL представляются в диалоговом окне редактора ACL Windows, так что они признаются достаточно близкими ACL Windows. Случайные пользователи вряд ли поймут различия. Разрешения POSIX ACL доступа соответствую разрешениям доступа Windows. Разрешения POSIX ACL по-умолчанию соответствуют наследственным разрешениям Windows.
Минимальные POSIX ACL состоят из трех записей, определяющих разрешения для владельца, группы-владельца и остальных пользователей. Это обязательные записи. ACL в Windows могут содержать произвольное количество записей, включая ноль. Если одна из записей в ACL не содержит разрешений, то пропуск записи не приводит к потере информации, запись спрятана от клиентов Windows. Если Windows клиент устанавливает ACL, в котором отсутствуют необходимые записи, разрешения в этой записи очищаются согласно POSIX ACL. Запись-маска в POSIX ACL не имеет своего аналога в ACL Windows. Если разрешения в POSIX ACL неэффективны из-за маскировки, то эти разрешения убираются из ACL в момент передачи через CIFS. Так как ACL в Windows поддерживают только псевдогруппы владельца-создателя и группы-создателя для наследования разрешений, то этим псевдогруппам будут соответствовать владелец и группа-владелец в ACL по-умолчанию. Для ACL доступа эти записи соответствуют именованным записям для текущего владельца и текущей группы-владельца (например, запись “u::rw” в POSIX ACL для файла, владельцем которого является Joe, расценивается как “u:joe:rw”). Если ACL доступа содержит именованные ACE для владельца и группы-владельца (например, если один из файлов, владельцем которого является Joe, имеет запись “u:joe:…”), разрешения, определенные в таких записях, не будут эффективными до тех пор, пока не сменится владелец, таким образом, такие именованные ACE игнорируются. Если Samba создает ACL, содержащий записи для владельца-создателя и группы-владельца, то этим записям предшествуют именованные записи для текущих владельца и группы-владельца соответственно. Записи в POSIX ACL доступа и ACL по-умолчанию, определяющие те же разрешения, что и записи ACL Windows, маркируются как определяющие доступ и правила наследования разрешений. 3.6 Резервные копии и восстановление Важным и наиболее легко рассматриваемым аспектом представления таких новых особенностей, как EAs и ACL, является создание резервных копий. Стандартные инструменты, такие как GNU tar и GNU cpio, не включают поддержки EA и ACL. Форматы архивов ustar и cpio, на которых основаны эти утилиты, не разрешают конкретные расширения, но до сих пор не было определено никакого стандарта хранения EAs или ACL. Текущая версия POSIX.1 [11] определяет новую утилиту pax, которая отвечает за взаимообмен перемещаемыми архивами. В добавление к своему новому формату архивов утилита pax поддерживает также форматы архивов ustar и cpio. Этот новый формат основан на ustar и, соответственно, в большой степени с ним совместим. Pax предоставляет механизм под названием расширенные заголовки. Расширенные заголовки, состоящие из списка атрибутов, очень похожи на EAs. Они используются для хранения вещей, которые не могут быть представлены в заголовках ustar, как например второе под-разрешение файловых временных штампов или размеры файлов в 8 Гб и более. Формат архивов pax отлично подходит для хранения EAs и ACL. Так как ни EAs, ни ACL не являются частью стандарта POSIX, то, соответственно, не определено специфического формата для использования EAs и ACL в расширенных заголовках. Спецификация оставляет место для специфических атрибутов производителя, помеченных его именем, так что даже если не может быть достигнуто никакого соглашения относительно использования форматов EAs и ACL, специфические расширения производителя могут быть по крайней мере достаточными и реализации могут поддерживать более одного расширения. Выгода в использовании формата pax состоит в том, что они могут быть распакованы с использованием реализаций tar. Для tar расширенные заголовки выглядят как файлы неизвестного формата. Информация, которая хранилась в расширенных заголовках будет потеряна, но все файлы и каталоги будут распакованы правильно. Это, правда, не будет работать для архивов pax, которые содержат файлы размером 8 Гб и более; это максимальный размер файлов в tar архивах. Существуют следующие решения для создания резервных копий (с последующим восстановлением) EAs и ACL: Реализация pax и tar Жогра Шиллинга (Jörg Schilling), названная star, включает поддержку POSIX.1e ACL и некоторых других. Полученные архивы являются переносимыми среди систем, которые реализуют различные версии POSIX ACL, включая FreeBSD, Irix, Compaq/HP Tru64, Linux, Solaris. Существует также патч, которые реализует поддержку Linux EA в star. Star доступен по адресу ftp://ftp.berlios.de/pub/star/. Для файловой системы XFS могут использоваться утилиты xfsdump (создание резервных копий) и xfsrestore (восстановление из резервных копий). Такой подход не рекомендуется в силу того, что формат резервных копий будет специфичен для конкретной файловой системы. Наконец, утилиты getfattr и getfacl могут сохранять ACL и EAs в текстовые файлы. Обратное преобразование производят утилиты setfattr и setfacl. Этот подход оправдан для восстановления целостных (единых) резервных копий, но он довольно непрактичен для восстановления отдельных файлов. 3.7 Поддержка ACL на уровне приложений В настоящее время наиболее основными инструментами, необходимыми для оперирования в операционной системе с EAs и ACL, то есть где основные файловые утилиты (ls, cp, и mv) поддерживают EA и ACL, являются утилиты управления EAs и ACL из командной строки, различные реализации системы резервного копирования, которая использует эти особенности. В настоящее время все еще существует много приложений, в которых не хватает такой поддержки. Хотя для большинства из них это неприемлемо, для некоторых классов приложений это приводит к различного рода проблемам. В этот класс входят файловые менеджеры, редакторы и инструменты синхронизации файловых систем. Файловые менеджеры обычно могут копировать и перемещать файлы и разрешать изменение разрешений доступа. Ядра UNIX не имеют функций копирования или перемещения файлов между границами файловых систем. Поэтому эти операции реализуются чтением содержимого файла-источника с последующим копированием этих данных в файл-назначение. По отдельным командам, передаваемым ядру, оно не может определить, производится ли сейчас копирование (или перемещение) файла или что-либо другое, то есть не может следить за соответствие этих операций правилам EAs и ACL. Это означает, что приложения должны сами по необходимости заботиться о соответствии всех выполняемых действий правилам EAs и ACL. Во многих утилитах существуют проблемы, связанные с копированием файлов. Существует два способа безопасного редактирования файла. Первый заключается в создании копии оригинального файла с последующей модификацией оригинала. Вторая заключается в переименовании оригинального файла и создании нового файла, который включает изменения оригинала. Второй способ эквивалентен копированию файлов в случае существования EAs и ACL. Существуют также дополнительные последствия для файлов, являющихся символическими ссылками, и файлов со счетчиком ссылок более единицы. Emacs и vi, наиболее популярные редакторы в UNIX-подобных системах, могут быть сконфигурированы для использования любого из этих методов.
Для сохранности разрешений важно сохранить настолько много информации, насколько это возможно. И, хотя это выглядит очевидно, правильная реализация этого не всегда тривиальна. Существует ряд сложностей, которые делают эти операции склонными к порождению ошибок в реализации. Это случается, например, если файл-источник и файл-назначение расположены на различных файловых системах, только одна из которых поддерживает ACL. Для того, чтобы освободить программистов необходимости предусматривать огромное количество возможных ситуаций, текущая версия libacl включает функции копирования EAs и ACL между файлами [8].
Также было бы замечательно, если поддержка EA и ACL была бы включена в такие популярные утилиты, как scp и rsync. К несчастью, утилиты, которые переносят файлы между различными файловыми системами, имеют намного более сложные несовместимости. Только некоторые UNIX-подобные системы поддерживают библиотечные функции POSIX.1e ACL, а остальные имеют свои собственные интерфейсы. Даже хуже, семантика ACL сильно различается среди одних только UNIX систем, не говоря уже о не-UNIX системах. Семантика и системные интерфейсы для EAs, к несчастью, также сильно различаются среди различных операционных систем.
4. ACL в Microsoft Windows 4.1 Защита файлов и каталогов 4.1.1 DACL и SACL Операционная система Windows NT 4.0 поддерживает файловые системы FAT и NTFS. Первая поддерживается такими известными операционными системами, как MS-DOS, Windows 3.x, Windows 95/98 и OS/2, вторая — только семейством Windows NT. У FAT и NTFS различные характеристики производительности, разный спектр предоставляемых возможностей и т.д. Основное отличие файловой системы NTFS от других (FAT, VFAT, HPFS) состоит в том, что только она одна удовлетворяет стандарту безопасности C2, в частности, NTFS обеспечивает защиту файлов и каталогов при локальном доступе. Защиту ресурсов с использованием FAT можно организовать с помощью прав доступа: чтение, запись, полный доступ. Таким образом, наиболее удачным с точки зрения безопасности будет создание дисковых разделы NTFS вместо FAT. Если все же необходимо использовать раздел FAT, то его надо сделать отдельным разделом для приложений MS-DOS и не размещать в нем системные файлы Windows NT. Поскольку файлы и каталоги в Windows NT являются объектами, контроль безопасности осуществляется на объектном уровне. Дескриптор безопасности любого объекта в разделе NTFS содержит два списка управления доступом (ACL) — дискреционный (DACL) и системный (SACL). В операционной системе Windows NT управление доступом к файлам и каталогам NTFS возлагается не на администратора, а на владельца ресурса и контролируется системой безопасности с помощью маски доступа (access mask), содержащейся в ACE соответствующего ACL. Маска доступа включает стандартные (Synchronize, Write_Owner, Write_Dac, Read_Control, Delete), специфические (Read(Write)_Data, Append_Data, Read(Write)_Attributes, Read(Write)_ExtendedAttributes, Execute) и родовые (Generic_Read(Write), Generic_Execute) права доступа. Все эти права входят в дискреционный список контроля доступа (DACL). Вдобавок маска доступа содержит бит, который соответствует праву Access_System_Security. Это право контролирует доступ к системному списку контроля доступа (SACL). В списке DACL определяется, каким пользователям и группам разрешен или запрещен доступ к данному ресурсу. Именно этим списком может управлять владелец объекта. Список SACL задает определенный владельцем тип доступа, что заставляет систему генерировать записи проверки в системном протоколе событий. Только системный администратор управляет этим списком. 4.1.2 Права и разрешения На самом деле для администрирования используются не отдельные права доступа, а разрешения NTFS. Разрешения подразделяются на: индивидуальные — набор прав, позволяющий предоставлять пользователю доступ того или иного типа (таблица 8.1); стандартные — наборы индивидуальных разрешений для выполнения над файлами или каталогами действий определенного уровня (таблица 8.2); специальные — комбинация индивидуальных разрешений, не совпадающие ни с одним стандартным набором (таблица 8.3). Таблица 8.1 – Индивидуальные разрешения в NTFS Разрешения Права доступа Операция над файлами папками Read Read_Control Read_Data Read_Atributes Read_EA Synchronize Операции чтения файла, просмотр атрибутов, прав доступа, а также имени владельца Операции отображения содержимого папки, просмотра атрибутов, прав доступа, а также имени ее владельца Write Read_Control Write_Data Append_Data Write_Atributes Write_EA Synchronize Операции изменения файла и его атрибутов, просмотра прав доступа и имени владельца Операции создания подпапок и файлов, изменения атрибутов файлов, просмотра прав доступа и имени владельца Execute Read_Control Read_Atributes Synchronize Execute Операции запуска программы, просмотр атрибутов, прав доступа, а также имени владельца Операции просмотра атрибутов и прав доступа, а также имени владельца и изменения подпапок Delete Delete Операции удаления файла Операции удаления папок Change permission Write_Dac Операции изменения прав доступа Операции изменения прав доступа Take ownership Write_Owner Операции изменения владельца файла Операции изменения владельца папки Таблица 8.2 - Стандартные разрешения в NTFS Разрешение Индивидуальные разрешения Операции No Access Нет Запрещение доступа к файлу. Пользователь, для которого оно установлено, не может получить доступ к файлу даже в том случае, если он входит в группу пользователей, имеющих права доступа к данному документу. Read Read, Execute Предоставление пользователю права на просмотр файлов и запуск приложений, хранящихся в папке. Change Read, Write, Execute, Delete Разрешение (дополнительно к правам, предоставляемым правом Read) на создание и удаление файлов и папок, модификацию содержимого файлов. Full Control Все Разрешение (дополнительно к правам, предоставляемым правом Change) на изменение прав доступа и вступление во владение файлами и папками. Таблица 8.3 - Специальные разрешения в NTFS Разрешение Разрешения к Операции
папкам файлам No Access Нет нет Запрещение доступа к папке и содержащимся в ней файлам. List Read, Execute Не устанавливает Разрешение на просмотр имен файлов и содержимого папок, а также их структуры. Read Read, Execute Read, Execute Предоставление пользователю права на просмотр файлов и запуск приложений, хранящихся в папке. Add Write, Execute Не устанавливает Разрешения (дополнительно к правам, предоставляемым правом Read) создавать папки и файлы. Не позволяет отображать структуру папок. Add & Read Read, Write, Execute Read, Execute Предоставление прав, указанных в правах Add и Read. Change Read, Write, Execute, Delete Read, Write, Execute, Delete Разрешение (дополнительно к правам, предоставляемым правами Add и Read) создавать и удалять файлы и папки, модифицировать содержимое файлов. Full Control Все Все Разрешение (дополнительно к правам, предоставляемым правом Change) на изменение прав доступа и вступление во владение файлами и папками 4.1.3 Улучшенная установка разрешений По умолчанию при инсталляции Windows NT в файловой системы NTFS устанавливаются довольно “свободные” разрешения, позволяющие обычным пользователям получать доступ к ряду системных файлов и каталогам. Например каталоги %systemroot% и %systemroot%\system32 имеют по умолчанию разрешение Change для группы Everyone. Если после установки Windows NT FAT впоследствии был преобразован в NTFS, то данное разрешение для этой группы устанавливается на все файлы и подкаталоги каталога %systemroot%. Защита данных каталогов заключается в грамотной установке разрешений. В таблице 8 приведены значения разрешений для каталогов. Вместо группы Everyone необходимо создать группу Users и использовать именно ее. Таблица 8 – Рекомендуемая защита системных каталогов Объект защиты Учетная запись Разрешение %Systemroot%\Repair Administrator Full control %Systemroot%\System32\Config Administrator Full control Creator Owner Full control Users List System Full control %Systemroot%\System32\SPOOL Administrator Full control Creator Owner Full control Users Read Power Users Change System Full control %Systemroot%\COOKIES %Systemroot%\ FORMS %Systemroot%\ HISTORY %Systemroot%\ OCCACHE %Systemroot%\ PROFILES %Systemroot%\ SENDTO %Systemroot%\ Temporary Internet Files Administrator Full control Creator Owner Full control Users Special Directory Access – Read, Write and Execute, Special File Access – None System Full control Существует несколько файлов операционной системы, расположенных в корневой директории системного раздела, которые также необходимо защитить, назначив следующие разрешения (таблица 9). Таблица 9 – Рекомендуемая защита некоторых системных файлов и каталогов Объект защиты Учетная запись Разрешение \Boot.ini, \Ntdetect.com, \Ntldr Administrators Full Control SYSTEM Full Control \Autoexec.bat, \Config.sys Administrators Full Control SYSTEM Full Control Everyone Read \TEMP directory Administrators Full Control SYSTEM Full Control CREATOR OWNER Full Control Users Special Directory Access – Read, Write and Execute, Special File Access – None Важно, что такие разрешения затруднят пользователям установку программного обеспечения. Также будет невозможна запись в .ini файлы в системном каталоге. Количество пользователей с правами администратора рекомендуется свести к минимуму. Учетную запись Guest лучше удалить, хотя она при установке (по умолчанию) и так отключена, а вместо этой учетной записи создать для каждого пользователя свою временную учётную запись с соответствующими разрешениями и правами.
4.2 Изменение разрешений NTFS с помощью программы Xcacls.exe 4.2.1 Введение В данном параграфе подробно рассмотрены вопросы использования программы Xcacls.exe (Extended Change Access Control List) для просмотра и редактирования разрешений NTFS для файлов и папок. С помощью Xcacls.exe можно установить все параметры безопасности для файловой системы, доступ к которым осуществляется из командной строки в проводнике Windows (с этой целью Xcacls.exe отображает и изменяет списки управления доступом (ACL) файлов). Рекомендуется использовать Xcacls.exe в процессе автоматической установки Windows 2000 Professional или Windows 2000 Server. С ее помощью устанавливаются исходные права доступа для папок, в которых располагаются файлы операционной системы. В процессе переноса программного обеспечения на серверы и рабочие станции Xcacls.exe обеспечивает одноступенчатую защиту от удаления пользователем файлов и папок. Программа Xcacls.exe входит в состав пакета Windows 2000 Resource Kit. Загрузить Xcacls.exe можно со следующего веб-узла корпорации Microsoft: http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/xcacls-o.asp 4.2.2 Синтаксис Xcacls.exe xcacls [/T] [/E] [/C] [/G :;] [/R ] [/P :; [ .]] [/D [ .]] [/Y] ,где — имя файла или папки, которой обычно назначается список (ACL) или запись (ACE) управления доступом. Могут быть использованы любые стандартные подстановочные знаки. /T - Рекурсивно просмотреть текущую и все вложенные папки, назначая указанные права доступа всем файлам и папкам, которые удовлетворяют определенным требованиям. /E - Редактировать список управления доступом (а не заменять его). Например, после выполнения команды {XCACLS test.dat /G Administrator:F} доступом к файлу test.dat обладает только учетная запись администратора. Все примененные ранее записи АСЕ отменяются. /C - Xcacls.exe продолжает работу даже после получения сообщения “Отказано в доступе”. Если параметр /C не указан, появление этого сообщения приводит к остановке программы. /G :; - Предоставить пользователю доступ к определенному файлу или папке. Переменная служит для назначения указанных прав доступа к файлам и определения особой маски доступа к файлам для папок. Переменная принимает следующие значения: Ø R чтение Ø C изменение (запись) Ø F полный доступ Ø P изменение разрешений (особый доступ) Ø O смена владельца (особый доступ) Ø X право запуска (особый доступ) Ø E чтение (особый доступ) Ø W запись (особый доступ) Ø D удаление (особый доступ) Переменная используется только с папками; принимает те же значения, что и переменная , или следующее особое значение: T - значение не определено - назначить запись ACE для папки без указания записи, которая используется с создаваемыми в этой папке файлами. Должно быть указано хотя бы одно право доступа. Текст между точкой с запятой и параметром Т не учитывается. Прочие параметры (также назначаются в проводнике Windows) представляют собой подмножество всех возможных комбинаций базовых прав доступа. По этой причине особые права доступа к папкам (например, LIST или READ) отсутствуют. /R Отменить права доступа для указанного пользователя. /P : ; Поменять права доступа для указанного пользователя. Переменные и определяются по правилам, описанным для параметра /G. /D Запретить пользователю доступ к файлу или папке. /Y Отменить вывод запроса на подтверждение изменения прав доступа. Программа CACLS выводит такой запрос по умолчанию. По этой причине, если команда CACLS используется в составе командного файла, его выполнение прерывается до получения ответа на запрос. Параметр /Y используется для подавления вывода окна запроса в случае использования Xcacls.exe в режиме пакетной обработки файлов. Важно отметить, что многие папки и файлы получают разрешения через механизм наследования. Следовательно, изменение разрешений для одной папки может повлиять на другие объекты. 4.2.3 Просмотр разрешений Программа Xcacls.exe используется для просмотра разрешений для файлов и папок. Например, после ввода в командной строке: xcacls C:\winnt, будет получен следующий результат: c:\WINNT BUILTIN\Users:R BUILTIN\Users:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_EXECUTE BUILTIN\Power Users:C BUILTIN\Power Users:(OI)(CI)(IO)C BUILTIN\Administrators:F BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F BUILTIN\Administrators:F CREATOR OWNER:(OI)(CI)(IO)F
Флаги списка управления доступом имеют следующее значение. Ø IO Только наследование (Inherit Only) — данная запись АСЕ не применяется к текущему объекту.
Ø CI Наследование контейнерами (Container Inherit) — данная запись АСЕ наследуется контейнерами более низкого уровня. Ø OI Наследование объектами (Object Inherit) — данная запись АСЕ наследуется файлами более низкого уровня. Ø NP Не распространять (Non Propagate) — объект более низкого уровня не передает дальше унаследованную запись АСЕ. Буква в конце каждой строки означает установленное право доступа. Например: Ø F полный доступ Ø C изменение Ø W запись 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 могут содержать идентификаторы как локальных, так и нелокальных пользователей и групп.
Текущие реализации POSIX ACL поддерживают только цифровые идентификаторы пользователей и групп в пределах локального домена. Поддержка нелокальных идентификаторов в ACL выглядит возможной, но сложной. Последовательная реализация может потребовать существенных изменений в модели. В минимальном случае в добавление к идентификаторам нелокальных пользователей и групп в ACE должна существовать поддержка владения файлом и группой для нелокальных пользователей и групп.

Используемые источники Кулик К.В., Усовершенствование методов распределения привилегий пользователей операционной системы Linux на основе системы RSBAC (система контроля доступа на основе набора правил), http://allunix.h12.ru/mywork/glava1.html Коньков К.А., Введение в операционные системы (Лекция 16. Защитные механизмы операционных систем), http://baclanout.abitu.ru/ims/c_yfks8/Osstud/glavs/glava16.html Кулябов Д.С., Учебно-методическое пособие по курсу “Защита информации в компьютерных сетях” Часть 1, М., 2004 Козинин Ф.А., Модели политики безопасности, http://re.mipt.ru/infsec/2004/essay/2004_Security_Policy_Models Kozin.pdf Goodheart B. & Cox J., The Magic Garden Explained: The Internals of Unix System V Release 4, Prentice Hall. http://www.amazon.com/exec/obidos/ISBN=0130981389/sunworldonlineA/ Vahalia, Uresh. Unix Internals: The New Frontiers, Prentice-Hall. http://www.amazon.com/exec/obidos/ISBN=0131019082/sunworldonlineA/ Stevens, Richard W., Advanced Programming in the Unix Environment, Addison-Wesley. http://www.amazon.com/exec/obidos/ISBN=0201563177/sunworldonlineA/ Сайт корпорации Microsoft - Microsoft Knowledge Base: http://support.microsoft.com/kb/318754/RU/ http://support.microsoft.com/kb/247603/RU/ Andreas Gruenbacher, POSIX Access Control Lists on Linux. www.suse.de/~agruen/acl/linux-acls/online/
Дополнительные источники 1. Curtis Anderson: xFS Attribute Manager Design. Technical Report, Silicon Graphics, October 1993. http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/attributes.pdf 2. Austin Common Standards Revision Group. http://www.opengroup.org/austin/ 3. Steve Best, Dave Kleikamp: How the Journaled File System handles the on-disk layout. IBM developerWorks, May 2000. http://www-124.ibm.com/developerworks/oss/jfs/ 4. B. Callaghan, B. Pawlowski, and P. Staubach: NFS Version 3 Protocol Specification. Technical Report RFC 1813, Network Working Group, June 1995. 5. Andreas Dilger: [RFC] new design for EA on-disk format. Mailing list communication, July 10, 2002. http://acl.bestbits.at/pipermail/acl-devel/2002-July/001077.html 6. Marius Aamodt Eriksen: Mapping Between NFSv4 and Posix Draft ACLs. Internet Draft, October 2002. http://www.citi.umich.edu/u/marius/draft-eriksen-nfsv4-acl-01.txt 7. Andreas Grünbacher: Known Problems and Bugs in the Linux EA and ACL implementations. March 20, 2003. http://acl.bestbits.at/problems.html 8. Andreas Grünbacher: Preserving ACLs and EAs in editors and file managers. February 18, 2003. http://www.suse.de/~agruen/ea-acl-copy/ for a description. 9. Hewlett-Packard: acl(2): Set a file's Access Control List (ACL) information. HP-UX Reference. http://docs.hp.com/ 10. Hewlett-Packard: acl(4): Access control list. Compaq Tru64 Reference Pages. http://www.hp.com/ 11. IEEE Std 1003.1-2001 (Open Group Technical Standard, Issue 6), Standard for Information Technology--Portable Operating System Interface (POSIX) 2001. ISBN 0-7381-3010-9. http://www.ieee.org/ 12. IEEE 1003.1e and 1003.2c: Draft Standard for Information Technology--Portable Operating System Interface (POSIX)--Part 1: System Application Program Interface (API) and Part 2: Shell and Utilities, draft 17 (withdrawn). October 1997. http://wt.xpilot.org/publications/posix.1e/ 13. Jim Mauro: Controlling permissions with ACLs. Describes internals of UFS's shadow inode concept. SunWorld Online, June 1998. 14. Microsoft Platform SDK: Access Control Lists. http://msdn.microsoft.com/ 15. Mark Lowes: Proftpd: A User's Guide March 31, 2003. http://proftpd.linux.co.uk/ 16. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck: NFS version 4 Protocol. Technical Report RFC 3010, Network Working Group, December 2000. 17. Silicon Graphics: acl(4): Access Control Lists. Irix manual pages. http://techpubs.sgi.com/ 18. J. Spadavecchia, E. Zadok: Enhancing NFS Cross-Administrative Domain Access. Proceedings of the Annual USENIX Technical Conference, FreeNIX Track, Pages 181-194. Monterey, CA, June 2002. 19. W. Richard Stevens: Advanced Programming in the UNIX(R) Environment. Addison-Wesley, June 1991 (ISBN 0-2015-6317-7). 20. Storage Networking Industry Association: Common Internet File System Technical Reference. Technical Proposal, March 2002. http://www.snia.org/tech_activities/CIFS/ 21. Sun Microsystems: acl(2): Get or set a file's Access Control List. Solaris 8 Reference Manual Collection. http://docs.sun.com/ 22. Sun Microsystems: NFS: Network file system protocol specification. Technical Report RFC 1094, Network Working Group, March 1989. 23. Robert N. M. Watson: acl(3): Introduction to the POSIX.1e ACL security API. FreeBSD Library Functions Manual. http://www.FreeBSD.org/ 24. Robert N. M. Watson: TrustedBSD: Adding Trusted Operating System Features to FreeBSD. USENIX Technical Conference, Boston, MA, June 28, 2001. http://www.trustedbsd.org/docs.html 25. Robert N. M. Watson: Introducing Supporting Infrastructure for Trusted Operating System Support in FreeBSD. BSDCon 2000, Monterey, CA, September 8, 2000. http://www.trustedbsd.org/docs.html 26. Robert N. M. Watson: Personal communication. March 28, 2003. 27. Winfried Trümper: Summary about Posix.1e. Publicly available copies of POSIX 1003.1e/1003.2c. February 28, 1999. http://wt.xpilot.org/publications/posix.1e/