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

Управление доступом в ОС 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].

Литература

  1. http://en.wikipedia.org/wiki/Unix_architecture
  2. Конявский В. А. Управление защитой информации на базе СЗИ НСД «Аккорд». — М.: Радио и связь, 1999. С. 50.

  3. Руководящий документ "Средства вычислительной тех­ники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации«//Гостехкомиссия России, 1992.

  4. Бажитов И. А. Возможности ПАК СЗИ НСД «Аккорд-Х» для ОС Linux//Комплексная защита информации: Сб. матер. XIV Междунар. науч.-практ. конф. (19 — 22 мая 2009 г.). — Мн., 2009. С. 26, 27.

  5. Руководящий документ "Автоматизированные системы. Защита от несанкционированного доступа к информа­ции. Классификация автоматизированных систем и требования по защите информации«//Гостехкомиссия России, 1992.

  6. Бажитов И. А. Обеспечение доверенной среды в ОС Linux с использованием ПАК СЗИ НСД «Аккорд-Х»// Комп­лексная защита информации: Сб. матер. XV Междунар. науч.-практ. конф. (1-4 июня 2010 г., Иркутск). — М., 2010. С. 32.

 


ФорумФорум
Форум ОКБ САПР
Вопросы специалистовВопросы специалистов
Вопросы, которые нам присылают, и наши ответы на них