Управление доступом в ОС GNU /Linux

А. М. Каннер
Закрытое акционерное общество «ОКБ САПР», Москва, Россия

Л. М. Ухлинов, д-р техн. наук
Открытое акционерное общество «Концерн „Сириус“», Москва, Россия

Операционные системы семейства Linux (пра­вильнее называть — семейство GNU/Linux) изна­чально получили широкое распространение как серверные ОС, однако сейчас ОС этого семейства постепенно все больше входят в жизнь каждого человека.

Ключевыми особенностями, из-за которых ОС семейства GNU/Linux становятся все популярнее, являются [1]:

• открытость исходных кодов большинства компонент системы (за исключением коммерче­ских, которые могут присутствовать в отдельных дистрибутивах). Лицензии по свободному исполь­зованию GNU/Linux позволяют беспрепятственно изменять исходные коды, что позволяет под­страивать ОС под выполнение конкретных задач. Кроме того, существует достаточно крупное сообщество GNU/Linux, оказывающее качест­венную и быструю поддержку ОС на базе ядра GNU/Linux, при этом процесс выпуска и утверждения обновлений строго систематизирован;
• наличие большого количества разнообразных дистрибутивов GNU/Linux и отсутствие единой принятой комплектации — т. е. ОС поставляется в виде ядра GNU/Linux (единое практически для всех дистрибутивов с точностью до релиза конк­ретного дистрибутива) и комбинацией много­образных прикладных программ и системных утилит. При этом пользователь может выбрать систему, удовлетворяющую исключительно его потребностям.

Крылатое выражение «In UNIX everything is a File, unless it isnt» описывает одну из опреде­ляющих черт ОС Unix и ОС, производных от нее, в том числе и GNU/Linux (далее такое множество будем для краткости обозначать как *nix) - за небольшим исключением (например, таких сущно­стей как сокеты и т. п.), любая сущность (объект) ОС представляется на уровне ОС в виде файла в дереве каталогов файловой системы (ФС). Что такое файл в *nix? Вообще говоря, это просто на­бор бит, причем какого-либо признака формата у файла может и не быть — чтобы понять (распознать) его содержимое нужно знать, что за данные в нем содержатся. Таким образом в *nix-системах:

• физические диски — есть файлы, так назы­ваемые файлы блочных устройств (располагаются в каталоге /dev), причем для передачи данных какому-либо устройству нет необходимости пере­давать их через драйвер — достаточно записать данные в файл устройства с помощью стандартной функции write (при этом система сама отошлет эти данные драйверу устройства);
• различные порты ввода / вывода — также есть файлы;
• обычные файлы (имеются ввиду пользова­тельские или системные файлы, содержащие какие-либо данные) — также есть файлы в ФС, за тем отличием от описанных выше объектов, что эти файлы имеют нефиксированный размер (его можно изменять), а также такие файлы можно читать непоследовательно из произвольных мест и т. д.

Очевидный плюс такого подхода к построению системы в том, что операции с любой сущностью (объектом) ОС производятся одинаково - точно так же как с обычным файлом. А для использова­ния в своих программах каких-либо устройств не нужно разрабатывать какой-либо дополнительный интерфейс взаимодействия (правда в данном слу­чае речь идет скорее только о данных, которые не имеют какого-либо специфичного формата, так как, например, отправить на печать изображение формата JPEG простой его записью в файл прин­тера не получится, для этого необходимо преобра­зовать данные в понятный для принтера формат, например, Postscript, что производится с помощью специального прикладного ПО). Другими словами в ОС *nix имеется некоторый механизм абстрак­ции представления объектов в ОС от механизмов взаимодействия с этими объектами.

Руководствуясь такой парадигмой становится очевидным, что для построения подсистемы раз­граничения доступа в *nix необходимо контроли­ровать как минимум такие операции как открытие файловых объектов на чтение/запись/выполнение, создание / удаление / переименование файловых объектов, переход в файловые объекты (в случае каталогов) и т. п. При этом по умолчанию кон­троль доступа к объектам ОС *nix может осущест­вляться штатными механизмами разграничения доступа, такими как:

• механизм дискреционного разграничения доступа (discretionary access control — DAC);
• механизм, реализующий списки контроля доступа (СКД или ACL — Access Control Lists);
• дополнительные средства разграничения дос­тупа, позволяющие реализовать в том числе меха­низм мандатного разграничения доступа (man­datory access control — MAC), например, SELinux, Tomoyo, AppArmor и пр. (данные сред­ства не входят в штатную комплектацию ОС *nix).

Механизм дискреционного разграничения дос­тупа является основным механизмом контроля доступа в ОС *nix. Данный механизм реализуется в виде прав доступа для файлов (объектов) ОС, при этом права доступа разделяются на:

• права владельца файла;
• права группы, владеющей файлом;
• права для остальных субъектов.

Кроме прав доступа на объекты ОС (права на чтение/запись/исполнение для владель­ца/группы/прочих субъектов доступа) в ОС *nix существует механизм, реализующий списки кон­троля доступа (СКД), который по сути позволяет расширить традиционные права доступа и на­страивать эти права доступа «индивидуально» на каждый объект ОС (т. е. указывать какой субъект доступа и что имеет/не имеет право делать с дан­ным объектом). Существенным минусом СКД яв­ляется невозможность их использования на всех ФС, поддерживаемых *nix, а также возможность отключения данного механизма на этапе загрузки ОС (например, через параметр ядра ОС acl_mode или с помощью опции no_acl в /etc/fstab, учиты­вающийся при монтировании определенного раз­дела).

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

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

Учитывая все вышеописанные недостатки штатных и внешних средств разграничения досту­па в ОС *nix и в соответствии со следствиями из теоремы об использовании компонента безопасно­сти (ИКБ) [2], в подсистему разграничения дос­тупа должен быть включен аппаратный компонент. Основная идея здесь сводится к тому, что без ис­пользования внешнего по отношению к системе резидентного компонента безопасности (именно аппаратного) невозможно построить решение (только программное) по контролю доступа к ин­формации. Данный аппаратный компонент при­зван в первую очередь осуществлять:

• идентификацию и аутентификацию (и/а) пользователя до начала загрузки ОС;
• контроль загрузки ОС с заранее определен­ного носителя информации;
• контроль неизменности оборудования ПК;
• контроль целостности загрузочных секторов носителя данных и отдельных разделов;
• контроль целостности определенных систем­ных файлов ОС.

В случае успешного прохождения всех кон­трольных процедур, выполняемых самим рези­дентным компонентом (независимо от аппаратных и программных составляющих ПК) должна про­должаться штатная загрузка ОС и подсистемы разграничения доступа в ОС. При всем при этом сама подсистема разграничения доступа должна уметь взаимодействовать с данным аппаратным компонентом с целью интеграции его защитных механизмов с механизмами разграничения доступа в ОС.

В случае же выявления какого-либо несоответ­ствия при проведении контрольных процедур -аппаратный компонент должен записывать соот­ветствующее событие в свой журнал и блокировать дальнейшую загрузку ОС. Таким образом, стано­вится возможным «обезопасить» подсистему раз­граничения доступа от отключения или изменения ее настроек на ранних этапах загрузки ОС.

Сама же подсистема разграничения доступа в свою очередь должна обеспечивать создание изо­лированной программной среды (ИПС), т. е. сре­ды, в которой каждому пользователю доступен только определенный набор возможных для ис­полнения процессов (программ, для которых кон­тролируется целостность), при этом для каждого процесса (как и для пользователя) ограничен круг доступных объектов ОС, а также в которой ис­ключена возможность запуска процессов вне такой среды пользователя [6].

Рассмотрим основные принципы построения подсистемы разграничения доступа на примере программно-аппаратного комплекса средств защи­ты информации от несанкционированного доступа (ПАК СЗИ НСД) «Аккорд-Х», разработанного компанией ОКБ САПР [4]. Функционально ПАК СЗИ НСД «Аккорд-Х» состоит из нескольких мо­дулей:

• монитора разграничения доступа (МРД), ко­торый должен запускаться в момент старта ОС до монтирования корневой файловой системы на за­пись (осуществляет основной функционал по разграничению доступа субъектов доступа к объектам ОС);
• подсистемы и/а пользователей в ОС, реали­зованной в виде РАМ-модуля (производит и/а пользователей в связке с МРД);
• подсистемы статического контроля целостно­сти (производит статический контроль целостности при получении указания от МРД);
• подсистемы журналирования (производит запись событий безопасности, полученных от МРД в специальный журнал);
• подсистемы контроля печати (осуществляет контроль печати на уровне подсистемы печати ОС во взаимодействии с МРД);
• утилит администрирования комплекса (слу­жат для редактирования БД пользователей МРД, а также для прочих настроек комплекса).

Ключевым элементом подсистемы разграниче­ния доступа является МРД, который выполнен в виде модуля ядра ОС. Данный модуль фактически выполняет весь основной функционал подсистемы разграничения доступа, а именно:

• в момент загрузки регистрирует собственные перехватчики основных системных вызовов в ядре ОС, тем самым, позволяя организовывать дискреционный и / или мандатный механизмы доступа в ОС (при этом права доступа могут задаваться как для пользователей, так и для отдельных процессов);
• всем процессам и пользователям на уровне ядра ОС присваивает определенные метки конфиденциальности (начиная с момента своей загрузки);
• контролирует права при монтировании разделов в соответствии с правами разграничения доступа (ПРД) в своей БД, при этом после монтирования дополнительно может проводиться статический контроль целостности в соответствии с системным списком контроля целостности из БД пользователей;
• при аутентификации пользователя в ОС осуществляет взаимодействие с подсистемой и/а пользователей (РАМ-модулем) и проверку введен­ных пользователем данных с данными в собствен­ной БД пользователей;
• по окончании сессии пользователя сбра­сывает признак аутентифицированности пользова­теля в собственных структурах с целью невоз­можности выполнения в ОС процессов от имени данного пользователя;
• производит статический и динамический контроль целостности данных:
  
  • статический контроль целостности осуществ­ляется сразу после успешной процедуры и/а пользователя;
  • динамический контроль целостности осуществ­ляется каждый раз при загрузке объекта доступа в память (производится самим МРД «на лету»);
• при перехвате любого системного вызова на получение доступа к объекту ОС проверяет ПРД в соответствии с собственной БД пользователей;
• фиксирует все события безопасности и передает их в подсистему журналирования.

Загрузка МРД в ядро ОС должна осуществ­ляться на раннем этапе загрузки операционной системы в связи с этим общий порядок загрузки ПК должен выглядеть следующим образом:

• при включении ПК управление передается штатному BIOS, который выполняет анализ и проверку подключенного оборудования;
• по окончании работы BIOS выполняется про­цедура RomScan, по окончании которой управле­ние передается аппаратному компоненту ПАК СЗИ НСД «Аккорд-Х» - аппаратному модулю доверенной загрузки «Аккорд-АМДЗ». На данном этапе для корректной работы ПАК СЗИ НСД «Аккорд-Х» необходимо дополни­тельно кроме прочих проверок контролировать целостность:
  
  • образа начальной загрузки системы initrd (МРД «Аккорд-Х» запускается из скрипта инициа­лизации образа initrd до выполнения /sbin/init);
  • ядра ОС vmlinux; МРД в виде файла на диске;
  • БД «Аккорд-Х» (в дальнейшем контроль БД осу­ществляется самим МРД, т. е. фактически БД поль­зователей после загрузки МРД защищает сама себя); прочих модулей ПАК СЗИ НСД «Аккорд-Х».

• после успешного прохождения контрольных процедур «Аккорд-АМДЗ» управление передается загрузчику ОС (который записан в boot-сектор загрузочного раздела /boot);
• загрузчик загружает ядро ОС и образ на­чальной загрузки в память, распаковывает образ начальной загрузки, загружает ядро ОС;
• в ядро ОС загружается МРД;
• ядро ОС запускает сценарий /sbin/init (первый пользовательский процесс);
• корневая файловая система монтируется на запись, запускаются необходимые службы ОС, монтируются дополнительные файловые системы в необходимые каталоги;
• после описанных выше шагов система оста­ется в режиме ожидания дальнейших действий (запускается утилита login для и/а пользователя).

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

Выводы

1. Встроенных (штатных) средств разграниче­ния доступа в ОС семейства *nix недостаточно для полноценной защиты от НСД к информации.

2. При использовании только программ­ных СЗИ практически всегда существуют способы их обхода, в связи с этим, наряду с программными компонентами, необходимо применять аппаратную часть, ликвидирующую недостатки только про­граммных средств.

3. Использование аппаратного компонента в СЗИ НСД является первой и, по большому счету, ключевой фазой при создании ИПС работы поль­зователя — в данном случае обеспечивается цело­стность аппаратной составляющей рабочей стан­ции, а также программной составляющей в лице ОС и критичных файлов подсистемы разграниче­ния доступа (т. е. осуществляется доверенная за­грузка ОС и ее компонент).

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

5. Целостный комплекс СЗИ в виде ПАК СЗИ НСД «Аккорд-Х» производства ОКБ САПР, в ко­тором реализован описанный выше подход в реа­лизации подсистемы разграничения доступа в ОС *nix, соответствует требованиям, предъявляемым к СЗИ НСД в соответствии с руководящими доку­ментами (РД) ФСТЭК России для 3-го класса защищенности СВТ [3] и для класса защищенно­сти АС 1Б [5].

Литература