Linux: к вопросу о построении системы защиты на основе абсолютных путей к объектам доступа

В докладе рассматриваются способы идентификации объектов доступа в ОС Linux как один из ключевых вопросов, стоящих перед разработчиком СЗИ для таких ОС, анализируются преимущества их преимущества и недостатки. Целью исследования является формулирование посылок, на которые необходимо опираться при выборе метода идентификации объектов доступа, в отличие от второстепенных посылок, опираться на которые ошибочно.

Ключевые слова: Linux, СЗИ НСД, объекты доступа, атрибуты доступа

Различные средства защиты от несанкционированного доступа (СЗИ НСД) в Linux, как это и следует из их предназначения, призваны разграничивать доступ различных субъектов доступа к объектам — т. е. к файловым объектам в рамках файловых систем (ФС) ОС. При этом штатные средства защиты в ОС руководствуются в своей работе атрибутами доступа к файловым объектам. Соответствующие же атрибуты доступа входят в состав мета-данных файловых объектов (сам же механизм разграничения доступа внешний по отношению к ФС), т. е. фактически «неотделимы» от самих данных, содержащихся в файлах — файл = метаданные + данные.

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

При разработке дополнительных «навесных» средств разграничения доступа перед разработчиком встает (по крайней мере должен встать) насущный вопрос — «каким образом идентифицировать защищаемые данные?» — т. е. как реализовать работу собственных политик разграничения доступа, чтобы защищать именно те данные, которые были поставлены на контроль?

Дать однозначный ответ не так просто. Можно воспользоваться по крайней мере следующими вариантами идентификации объектов доступа в ОС Linux:

1. использование абсолютного пути (absolute path) к файловым объектам;
2. использование прав разграничения доступа (ПРД) на основе своих атрибутов в метаданных файловых объектов (т. е. добавление своих метаданных);
3. использование не абсолютного пути к объекту в ФС, а разграничение доступа к объектам виртуальной файловой системы (VFS) ядра ОС Linux — inode/dentry и т.п. (т. е. фактически к самим метаданным, по которым осуществляется доступ к данным).

Кратко рассмотрим каждый из перечисленных вариантов.

Использование абсолютных путей в ПРД

Наиболее очевидным способом задания ПРД для объекта доступа является указание абсолютного пути к этому файловому объекту в ОС. К сожалению данный подход при задании ПРД для СЗИ НСД в ОС Linux при всей своей простоте кроет в себе существенные недостатки, а именно:

• неоднозначность абсолютного пути до защищаемого объекта при изменении правил монтирования файловых систем (при разбиении корневой ФС на несколько различных ФС, например, если изменить правила в /etc/fstab);
• возможность «смонтировать» каталог, содержащий защищаемый объект в другую точку монтирования (из которой можно получить доступ к файловому объекту, используя другой абсолютный путь);
• возможность смены корневого каталога с последующим обращением к защищаемому объекту фактически по относительному пути (chroot);
• возможность при переименовании объекта избежать действия ПРД;
• возможная несвязанность файлового объекта с защищаемыми данными (например, объект доступа может являться символической ссылкой);
• и т.д..

Перечисленные недостатки приводят нас к тому, что в СЗИ НСД в ОС Linux кроме стандартых механизмов разграничения доступа должны присутствовать:

1. механизм контроля точек монтирования — т. е. СЗИ НСД должно контролировать монтирование разделов (каталогов) в различные точки ФС (правила для монтирования при загрузке ОС можно полностью скопировать из /etc/fstab), а при нарушении правил монтирования — не выполнять монтирование. Такие правила можно дополнительно составлять отдельно для различных пользователей.
2. механизм "пополнения«/изменения ПРД, например, при создании новых объектов или переименовании существующих.

Особые проблемы появляются при возникновении необходимости одновременно смонтировать ФС в две точки монтирования — в данном случае при обращении по разным абсолютным путям к объектам доступа СЗИ НСД должно либо перенести вопрос правомерности такого доступа на пользователя (администратора), либо само перебирать на уровне ядра ОС всевозможные точки монтирования для объекта (структура vfsmount) и запрещать доступ, если доступ запрещен хотя бы в одной точке монтирования. Аналогичным образом СЗИ НСД должно поступать в случаях, когда на уровне ядра не представляется возможности определить точку монтирования (если файловый объект располагается на отличной от корневой ФС - на уровне ядра путь к объекту иногда можно определить только относительно точки монтирования этой ФС, т.е. путь будет относительным).

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

Дополнение метаданных собственными атрибутами доступа

В данном случае, как и в случае со штатными атрибутами доступа в ОС, дополнительные атрибуты доступа предполагается хранить вместе с метаданными файловых объектов (в некотором дополнительном атрибуте ФС или как-то иначе), а не отдельно от них и соответственно от самих данных. Используя такой способ «привязки» атрибутов доступа к данным, удается избежать всех недостатков идентификации субъектов доступа по абсолютному пути:

• в случае изменения порядка монтирования ФС в ОС, при монтировании каталога с защищаемыми объектами доступа к какой-либо другой точке монтирования или при смене корневого каталога (chroot) ПРД будут продолжать действовать, т.к. «связанность» атрибутов доступа с данными в данном случае не нарушается (в отличии от случая использования абсолютных путей);
• в случае переименования объекта доступа или при обращении к этому объекту с использованием символических ссылок ПРД будут также учитывать атрибуты доступа самого объекта доступа (дополнительного «пополнения» ПРД самим СЗИ в случае переименования объекта доступа не требуется).

Даже в случае переноса носителя данных на другое СВТ, в случаях копирования данных или при переустановке ОС легко возобновить работу СЗИ, т.к. атрибуты доступа будут переноситься вместе с самими данными (если это будет поддерживаться в соответствующих ФС).

Кроме всего прочего необходимо отметить, что при таком дополнении метаданных объектов доступа отсутствует необходимость в контроле точек монтирования, однако механизм «пополнения» ПРД при создании новых объектов доступа должен присутствовать (нужно заносить некоторые стандартные атрибуты доступа в метаданные созданного объекта).

Отрицательной чертой такого подхода является то, что фактически изменяются сами данные (добавление метаданных — тоже изменение файла), что может вызвать подозрение как у администратора, так и у некоторых средств защиты (HIDS, Host Intrusion Detection System). Кроме того этот подход может быть недоступен для некоторых типов файловых систем (или как минимум будет требовать отдельной реализации для многих типов файловых систем, которых в ОС Linux поддерживается огромное количество).

Контроль доступа к структурам VFS в ядре ОС Linux

Рассмотрим вариант адаптации метода использования абсолютных путей для идентификации объектов доступа. Существует вариант контроля доступа к данным не по абсолютным путям к файловым объектам, а с использованием механизма контроля доступа к объектам, представляющих собой сами файловые объекты на уровне ядра ОС Linux — inode/dentry и т.п. Поскольку такие объекты формируются при загрузке ядра ОС (вообще говоря, при загрузке соответствующего модуля ядра для поддержки определенного типа ФС и после монтирования раздела с таким типом ФС), то изначально все равно придется использовать абсолютные пути до объектов доступа. Однако после монтирования всех необходимых ФС открывается возможность «сопоставить» абсолютные пути для всех заданных объектов доступа конкретным inode/dentry на уровне ядра ОС и контролировать доступ именно к ним (а не пытаться каждый раз построить абсолютный путь по известным inode/dentry). Такой подход позволяет:

• частично избавиться от неоднозначности при изменении порядка монтирования ФС (inode/dentry будут оставаться неизмененными, будет изменяться структура, определяющая точку монтирования — vfsmount);
• решить проблему с переименованием объекта (в рамках текущей работы ОС) и обращениями по символьным ссылкам (в любом случае доступ будет осуществляться в inode/dentry, однако дополнительно нужно занести inode-объект, а не его ссылку, в ПРД).

При всех плюсах такой метод контроля доступа необходимо сочетать с уже перечисленными механизмами контроля точек монтирования (как минимум это требуется в самом начале для корректного «сопоставления» абсолютных путей с inode/dentry) и "пополнения«/изменения ПРД (например, для тех же объектов-ссылок или создаваемых объектов). Кроме того должен присутствовать механизм, который будет решать, что делать с объектом (по абсолютному пути), которого в системе уже нет (но, возможно, может появится, например, при дальнейшей загрузке или работе ОС), — в какой момент строить для него «соответствие» и строить ли вообще.

Выводы

При выборе СЗИ часто (если не всегда) неочевидно, каким образом оно идентифицирует защищаемые объекты ОС и правильно ли вообще функционирует. Кроме того, вопрос идентификации объекта доступа граничит с «доступностью» этого метода для понимания рядовым пользователем/администратором. В связи с этим достаточно многие СЗИ строятся на базе идентификации объекта доступа по абсолютным путям (что, несомненно, является наиболее простым для понимания способом), не вводя дополнительно в ОС Linux каких-то сторонних механизмов защиты, описанных в данной статье. Если говорить про ОС семейства Windows — такие дополнительные механизмы, как контроль точек монтирования, там вообще избыточны (если не изменена конфигурация и порядок подключения носителей информации, то нумерация и обозначение разделов, а также абсолютные пути всегда будут неизменными).

Мы в ОКБ САПР стараемся учитывать особенности
защищаемой среды (если говорить о данной статье — особенности ОС семейства Linux) при проектировании своих СЗИ.
Механизм контроля точек монтирования изначально включен в продукт ОКБ САПР ПАК
СЗИ НСД «Аккорд-Х», дополнительные механизмы постепенно внедряются и находят
свое место в этом решении.

Автор: Каннер А. М.

Дата публикации: 01.01.2013

Библиографическая ссылка: Каннер А. М. Linux: к вопросу о построении системы защиты на основе абсолютных путей к объектам доступа // Информационная безопасность. Материалы XIII Международной конференции. Таганрог 2013. Часть. 1. С. 118–121.

---