Укрепленный форт Castle

По мере роста популярности ОС Linux все большее значение приобретает обеспечение информационной безопасности систем, построенных на ее основе. Как и в разнообразных клонах Unix, в Linux имеются все базовые инструменты защиты, однако часто их не хватает для надежной защиты конфиденциальных данных. Защита совершенствуется в трех направлениях: безопасность отдельных компонентов, усиление ядра и разработка защищенных дистрибутивов.

Разработчики свободно распространяемого программного обеспечения стремятся усовершенствовать средства защиты в операционной системе Linux, работая в трех направлениях: безопасность отдельных компонентов системы (аутентификация, служебные программы); усиление защитных возможностей ядра (проекты OpenWall Kernel patch, International Crypto patch, RSBAC, LIDS, Medusa, SELinux, LIDS); разработка защищенных дистрибутивов (Trustix, Kalladix, Owl, Castle). Особый интерес представляют защищенные дистрибутивы, позволяющие быстро установить и настроить комплексную систему защиты. Один из таких дистрибутивов предлагает российская компания ALT Linux. Речь идет о Castle, защита в котором построена на основе механизма RSBAC (Rule Set Based Access Control — контроль доступа по установленным правилам), дополненного другими средствами защиты. Наши читатели уже могли познакомиться с RSBAC [1], однако, рассказывая про Castle, целесообразно рассмотреть его базовый инструментарий защиты подробнее.

Архитектура RSBAC

RSBAC, функционирующий на уровне ядра, состоит из двух компонентов: дополнения исходного кода ядра (patch) и модули правил. RSBAC добавляет свои собственные проверки к системным вызовам. Как результат, логика работы ядра не меняется, но его интерфейсная часть дополняется новыми возможностями. Архитектура GFAC (General Framework for Access Control Approach), по которой работает RSBAC, предложена одним из разработчиков мандатного доступа Ла-Падула и впервые реализована в SystemV/MLS. В этой архитектуре механизм защиты делится на три части: модуль контроля системных вызовов (Access Enforcement Facility — AEF), модуль принятия решения (Access Decision Facility — ADF) и хранилище информации о правах доступа (Access Control Information — ACI).

Рис. 1. Архитектура GFAC

Работает такая защита следующим образом (рис. 1): системный вызов (их в Linux около двух сотен) преобразуется в один из стандартных запросов к модулю принятия решения (их в RSBAC около 30), который, «посовещавшись» с другими модулями, выносит вердикт — разрешить или запретить дальнейшее выполнение системного вызова. Модули защиты получают информацию для принятия решения из атрибутов участников системы, которые хранятся в ACI. Архитектура GFAC позволяет сделать защиту независимой от типа операционной системы (достаточно заменить модуль AEF, сохранив все остальные модули) и обеспечить одновременную работу нескольких независимых друг от друга модулей правил безопасности. Архитектура GFAC позволяет оснащать механизмом RSBAC (www.rsbac.org) различные операционные системы.

RSBAC не занимается аутентификацией пользователей, проверкой целостности файлов, контролем доступа к фрагментам файлов и другим операциям, которыми не может управлять ядро. Так, если программа имеет права на доступ к файлу /etc/passwd для записи нового пользователя, то это означает, что ей позволено изменять весь файл целиком, а не отдельную запись; однако такая «неизбирательность» не всегда допустима. Поэтому в защищенной системе механизм RSBAC логично сочетать с другими средствами защиты, которые работают на более высоком уровне приложений. С помощью RSBAC можно добиться реализации принципа минимизации полномочий процессов и пользователей, причем не только на уровне отдельных идентификаторов пользователя UID, но и в зависимости от роли, которую исполняет процесс с конкретным UID. Разработчикам Castle пришлось проделать большую работу, чтобы сделать видимыми для ядра и RSBAC операции, критичные с точки зрения безопасности.

В Castle в соответствии со схемой функционирования RSBAC есть два привилегированных пользователя: root, который занимается администрированием, и secoff, контролирующий права доступа. При этом root, «всесильный администратор», не может ни повлиять на защиту RSBAC, ни прочитать значительную часть хранимой в системе информации. Так, в Castle по умолчанию пользователь с правами root не может читать информацию пользователей из каталога /home. Администрированием прав RSBAC занимается «офицер безопасности» secoff, который в остальном — обычный пользователь, неспособный своими действиями повредить систему. Тем не менее, только у него есть полномочия на изменение поведения защиты RSBAC. Офицеров безопасности может быть несколько; каждый из них наделяется уникальным набором полномочий. В результате, взлом системы многократно усложняется, поскольку для полного захвата необходимы привилегии права администратора и офицера безопасности, при том что каждый из них контролирует действия другого.

Установка RSBAC

В Castle компонент RSBAC устанавливается по умолчанию в некоторой хорошо проверенной конфигурации. Если возникла потребность обновить RSBAC, придется пройти всю процедуру установки с начала. Для установки RSBAC нужно загрузить с сервера компании ALT Linux дополнения к ядру соответствующей версии, наложить их командой patch на исходные тексты ядра, сконфигурировать и скомпилировать ядро. Какие именно модули должны использоваться, указывается при конфигурировании ядра. Чтобы добавить новый модуль, придется перекомпилировать ядро. Однако если ядро уже собрано с поддержкой требуемого модуля, то его можно включать и выключать даже без перезагрузки системы. Наиболее важен модуль AUTH, контролирующий изменение идентификаторов пользователя UID для процессов. Этот модуль необходим в любой конфигурации RSBAC, поскольку используется остальными модулями для собственной защиты.

Прежде чем загрузить Linux с новым ядром, следует также откомпилировать административные утилиты из дополнительного архива. Для сборки утилит необходимо иметь в системе исходные тексты ядра с наложенными на него дополнениями RSBAC. Иногда возникает ситуация, что RSBAC перестает подчиняться офицеру безопасности; тогда лучше всего включить так называемый «мягкий режим». При работе в этом режиме RSBAC будет выдавать все положенные сообщения, но не станет блокировать действия. Включается он с помощью специального параметра rsbac_softmode во время загрузки ядра или уже непосредственно в ходе работы ОС. Этот режим предназначен для проверки работоспособности системы с новыми правилами защиты и для выхода из ситуации, когда контроль над системой потерян.

Чтобы правильно установить систему защиты, полезно ознакомиться со статьей [2] и документацией к RSBAC. В Castle по умолчанию включены: файлы с флагами, списки доступа и ролевая модель. Однако есть модули, без которых RSBAC просто не будет работать: это AUTH и модуль протоколирования. Этих модулей достаточно для решения большинства задач безопасности. Тем не менее, нужно помнить, что каждый модуль решает определенный круг задач и потому лучше использовать их по назначению, а не пытаться решить все проблемы безопасности, например, с помощью модуля RC. Разработчики Castle проделали большую работу по минимизации полномочий. Правила защиты, принятые в дистрибутиве по умолчанию, с одной стороны, не мешают нормальной работе системы, а с другой — не позволяют пользователям превышать свои полномочия. В частности, всякое действие администратора по добавлению нового пользователя или программы требует подтверждения со стороны офицера безопасности. В домашнем каталоге офицера безопасности есть для этого соответствующие скрипты.

Смена владельца

Основа защиты в RSBAC — мониторинг поведения процессов, и, в частности, перехода процессов от одного пользователя к другому. Для решения этой задачи в RSBAC используется модуль AUTH, разрешающий смену владельца только определенным процессам и только на определенные значения UID. Этот достаточно простой модуль лимитирует поведение программ, которым не требуется смена пользователя. К таким программам, в частности отнесено большинство клиентских систем, таких как почтовые программы, браузеры, текстовые процессоры и т.п.

В RSBAC заложена возможность создания отдельной службы, которая не может сама менять владельца, но предоставляет эту привилегию другим программам. С помощью этой службы удается разделить процедуры аутентификации и авторизации пользователей. Так, программа login, изначально не имеющая полномочий менять владельца, принимает от пользователя идентификационную информацию и передает его в службу аутентификации. Та анализирует идентификационную информацию и отправляет результат в службу авторизации, которая выдает login право на смену владельца на конкретное значение UID, полученное от службы аутентификации.

В частности, с помощью модуля AUTH можно запретить превращения администратора в любого другого пользователя без дополнительной проверки пароля, что допускается на уровне ядра, не оснащенного RSBAC. Как результат, root не всегда может получить права другого пользователя, а только через привилегированные программы. Однако даже привилегированные программы могут изменить свой идентификатор пользователя UID в строго ограниченных рамках. В дистрибутиве ALT Linux Castle даже программам login и ssh, которые занимаются авторизацией пользователей, разрешено производить смену UID только в диапазон значений, которые соответствуют реальным пользователям. Благодаря этому, в частности, нельзя авторизоваться в системе под именем пользователя bin или daemon.

Файлы с флагами

Модуль FF, реализующий привязку к файлам и каталогам определенных атрибутов, — один из самых простых, удобных и часто используемых. Он позволяет устанавливать полномочия на целые иерархии каталогов, поскольку права родительского каталога наследуются всеми потомками, кроме выделенных исключений. Так, с помощью этого механизма в Castle каталог с библиотеками и исполняемыми системными файлами целиком может получить флаг «только для чтения».

Ролевой доступ

Суть ролевой модели доступа заключается в том, что разграничение прав зависит не от отдельных субъектов (процессов) и объектов (ресурсов) операционной системы, а от заранее определенных ролей субъектов, в которых участвуют объекты. Такая модель разграничения прав позволяет обезопасить поведение сложных программ, таких как Apache или login. Например, процесс httpd (Apache) имеет несколько подчиненных процессов, которые, хотя и называются одним и тем же именем и работают под тем же UID, с точки зрения RSBAC играют разные роли. Мастер-процесс принимает запрос и передает его подчиненным процессам, которые обрабатывают и выдают результат. RSBAC знает, что может делать мастер-процесс, а что подчиненные, и в состоянии блокировать нелигитимные действия. При этом роли не привязаны к пользователям, а определяются по их поведению. Существуют роли, привязанные к конкретным идентификаторам UID (скажем, оболочка bash), а также не соответствующие никаким пользователям (например, сервер Apache, который должен иметь доступ к файловой системе, где лежит все содержание Web-ресурса). Если на одном компьютере работает несколько экземпляров Apache, каждый из которых должен иметь доступ только к своему содержимому, то в традиционной Unix-модели подобное разделение прав реализовать достаточно сложно. С точки зрения ролевой модели каждый экземпляр Apache относится к своей роли и не имеет доступа к информации «соседнего» Web-сервера.

Впрочем, случай с Apache несколько сложнее, поскольку один процесс может работать с несколькими виртуальными Web-ресурсами. При этом подчиненный процесс может обслуживать в разные моменты времени разные ресурсы; поэтому нужно, чтобы мастер-процесс сам объявлял RSBAC, какую роль он передает своему подчиненному процессу. Это, естественно, требует интеграции RSBAC и Apache, и программный интерфейс для такой интеграции открыт. (Команда разработчиков ALT Linux пока не реализовала данную схему контроля поведения Web-сервера.)

Из ролей можно выстраивать иерархические структуры подчинения, например, определить роль, которая будет администрировать другую, или же фиксировать последовательность переключения ролей. Есть также возможность создать такую роль, которая будет назначать субъектам какие-то роли. Для каждой роли можно определить, какого типа файлы и процессы роль создает по умолчанию. Кроме того, определяются права доступа к объектам конкретного типа. В последней версии RSBAC появилась возможность определения подроли (одну роль можно разделить на несколько более мелких).

Ролевую модель реализует модуль RC. В определении роли содержится информация о программах, ей отвечающих, и о соответствующих правах доступа к ресурсам. Например, можно создать роль, которой позволено читать и редактировать файл /etc/passwd, связав с ней только команды adduser и login. Администратор, с помощью rsu переключив свою роль, сможет добавить пользователя — но не подправить этот файл текстовым редактором [2].

В Castle ролевая модель используется для блокирования доступа администратора root в домашние каталоги пользователей. Для этого служат «домашний каталог« и роль «пользователь». Администратор root не имеет доступа к объектам, помеченным как «домашний каталог«, зато пользователи имеют все права на доступ к ним. Аналогичным образом защищены и конфигурационные файлы RSBAC, хранящиеся в каталоге /secoff; доступ к ним имеет только администратор безопасности. Домашний каталог офицера безопасности вынесен намеренно, чтобы пользователь root иногда мог добавлять новых пользователей в домашний каталог /home, но даже временно не получал бы доступа к каталогу, где хранится конфигурация RSBAC.

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

Списки доступа

Метод описания полномочий доступа с помощью списков разрешенных операций, прикрепленных к файлам, используется достаточно давно. Списки контроля доступа (ACL — Access Control List) уже интегрированы в отдельные файловые системы, такие как ReiserFS или XFS, поставляемые в составе Castle. Со своей стороны, RSBAC позволяет добавить и собственный механизм ACL, интегрировав его с другими моделями защиты, например, с ролевым доступом. А поскольку в RSBAC контролируются не только операции доступа к файлам, но и все важные системные вызовы, то и их можно указывать в списках контроля доступа. Можно также определять группы пользователей, для которых создаются свои списки доступа. Есть глобальные группы пользователей, которые доступны всем, а есть «приватные» группы, видимые только ее членам.

С точки зрения модели ACL в RSBAC для каждого файла определяется основная маска, которая соответствует модели «для всех» в традиционной файловой системе Unix. Кроме того, заводятся дополнительные записи на пользователя, на ACL-группу и на роль. Благодаря этому в RSBAC можно более точно настраивать списки доступа, используя для этого и ролевую модель распределения полномочий. В списках ACL помимо традиционных прав можно указать еще и дополнительные. В RSBAC по умолчанию владелец файла не может изменять права доступа к своему файлу, и эту привилегию он может получить в ACL. Пользователей в списках можно указывать непосредственно, а можно через группы. У каждой такой ACL-группы есть владелец, который может добавлять новых членов группы, удалять и передавать свои полномочия другому пользователю, после чего теряет контроль над группой.

Маски привилегий

В последней версии RSBAC появился новый модуль, которые реализует модель маски привилегий Unix, закрепленный в стандарте POSIX. Эта модель была придумана для того, чтобы в рамках классического варианта Unix минимизировать полномочия процессов, выполняемых от имени привилегированных пользователей. Например, сервер NTP, который контролирует системное время, может выполняться от имени непривилегированного пользователя, не имеющего никаких особых полномочий, кроме одного — менять системное время. В рамках этой модели субъект обладает определенным набором таких привилегий, которые у него можно отобрать, оставив необходимые для выполнения его обязанностей.

В RSBAC модель маски привилегий дополняется всеми остальными возможностями системы, в частности, можно для файла указать список привилегий, которые потребуются пользователю. Фактически, это аналог атрибута SUID, но только с возможностью более точного распределения прав. Стандарт POSIX определяет правила работы с масками привилегий, но пока ни в одной операционной системе они не были реализованы. Этот модуль совмещает инфраструктуру RSBAC и стандартные привилегии POSIX. В результате можно построить гибкую систему защиты без использования более сложных механизмов, таких как роли или списки доступа.

Протоколирование

В RSBAC можно протоколировать практически все системные вызовы, которые, как уже ранее отмечалось, преобразуются в стандартные запросы. Можно указать глобальные настройки системы протоколирования, определяющие поведение всей системы по умолчанию. Протоколировать можно все запросы, только отказы в обслуживании или определенные группы запросов. Кроме того, можно для каждого файла или другого объекта указать список действия и правила их протоколирования. Можно также протоколировать и общее поведение процессов: смену владельцев, объекты чтения и другие параметры. С помощью подробного протоколирования можно тестировать систему защиты, выясняя, какие полномочия нужны процессу для нормальной работы.

Кроме того, протоколирование событий ведется по двум независимым каналам: один для сообщений RSBAC, а другой для всех остальных. Это позволяет вести независимое протоколирование событий, относящихся к администратору системы и офицеру безопасности, причем каждый из них не может посмотреть протоколов другого. Впрочем, можно сделать и так, чтобы ни тот, ни другой не могли посмотреть ни одного протокола, а права на это имелись только у третьего независимого пользователя.

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

В следующей версии RSBAC, как предполагается, появятся и другие дополнительные возможности. В частности, ожидается появление модуля распределения полномочий, при использовании которого будет еще один привилегированный пользователь — «нотариус», который выдает временные полномочия администратору и офицеру безопасности для выполнения той или иной задачи. В определении задачи описывается, какие именно действия и в какой последовательности могут выполнить участники системы. Кроме того, в новой версии появляется возможность создавать временные ACL-записи и временные роли, которые по истечении указанного времени аннулируются. Появится и дополнительный модуль для контроля сеансов связи.

Дополнительные особенности Castle

Установка RSBAC в дистрибутиве Castle позволяет добиться высокого уровня защищенности, однако на этом возможности защиты не ограничиваются. В Castle включены дополнительные меры, позволяющие еще более усилить защищенность системы. Принципы построения защищенных серверов на основе Castle описаны в [3].

Понижение полномочий серверов

В традиционных клонах Unix службы, которые обрабатывали различные запросы из Internet, запускались от имени пользователя с правами root. В результате, если злоумышленник находил какую-нибудь ошибку в реализации службы, то сразу мог получить полномочия администратора и проникнуть в систему. Однако, как можно заметить, службы эти самодостаточны: удается сделать так, чтобы они работали со своим набором прав и со своими файловыми объектами, выполняя свои задачи, но никак не влияя на остальную систему.

С этой целью предложен способ понижения полномочий сетевых служб с помощью команды chroot (изменить корневой каталог), которая позволяет локализовать для конкретного процесса одно из поддеревьев файловой системы. Однако оказалось, что большинство уже написанных программ не может работать в таком ограниченном фрагменте системы, поэтому пришлось корректировать реализацию служб, чтобы обеспечить их автономность. Сейчас появились такие локализованные реализации для FTP, NTP, POP3, DNS, SMTP и СУБД MySQL, PostgreSQL.

В ряде дистрибутивов Linux (в том числе, и в Castle) каждая из безопасных служб локализована в отдельном поддереве, к тому же сами они запускаются от имени непривилегированных пользователей. В сочетании с выделением для них лишь части файловой системы это позволяет ограничить их действие лишь небольшой частью системы. В результате, даже если злоумышленник сможет «взломать» конкретную службу, он не получит контроля над всей системой. RSBAC предоставляет более полную информацию для контроля поведения таких служб, в частности, с его помощью можно ограничить полномочия root по вмешательству в действия сетевых служб, без согласия офицера безопасности.

Аутентификация

В стандартной модели аутентификации Unix все пароли пользователей хранятся в файле /etc/passwd или /etc/shadow. В случае необходимости внести изменение в этот файл, программа, получившая к нему доступ на запись, может изменить не только то, что ей требуется, но и пароли других пользователей. Если же в момент санкционированного внесения изменений (например, в ходе работы программы adduser) произошел сбой, и программа совершила несанкционированные действия с другой записью, то отследить это практически невозможно. Проблема еще более усугубляется, если привилегированных пользователей несколько.

Чтобы решить эту проблему, в рамках проекта OpenWall Linux (Owl) реализовали систему, которая в отдельных файлах хранит кэши паролей и еще некоторую информацию для каждого пользователя. Если программе нужно сменить пароль, то она получает доступ только к идентификационной информации конкретного пользователя, а не ко всей базе и можно правильно настроить защиту даже с помощью прав доступа, принятых в Unix. В частности, эта схема хранения паролей реализована в дистрибутиве ALT Linux Master. В Castle предусмотрена специальная схема проверки паролей, при которой проверку идентификационной информации выполняет особая привилегированная программа, а остальные процессы, которые имеют на это разрешение, могут посылать запросы только этой процедуре. Получается двойной контроль: непривилегированные программы самостоятельно пароли не проверяют, но имеют право запустить специальную процедуру проверки.

Разделение идентификационной информации для различных пользователей позволяет реализовать модель не парольной идентификации, используя, например, для этого внешние устройства хранения (аппаратный USB-ключ). В этом случае идентификационной файл будет хранить не пароль, а другую информацию, например, сертификат или открытый ключ. Тогда в момент проверки полномочий данные шифруются открытым ключом и отправляются на устройство идентификации, а аутентификация будет завершена после положительного ответа внешнего устройства. Можно сочетать парольную и непарольную аутентификацию, поскольку информация о методе аутентификации хранится в отдельном файле.

Всего понемногу

В Castle использовано много различных приемов, улучшающих общую защищенность системы и применяемых совместно с другими, более универсальными средствами защиты, подобными RSBAC. Так, в Castle интегрирована система шифрования хранимой информации Kernel International Crypto patch, которая позволяет защитить конфиденциальность даже в случае, когда злоумышленник получил доступ напрямую к жесткому диску. Эта система привязана к конкретному ядру и при попытке его подмены отказывается расшифровывать информацию. Поскольку удалить RSBAC можно только вместе с ядром, то и прочитать зашифрованные данные можно только под контролем RSBAC.

Разработчики Castle очень придирчиво отбирали программы, поставляемые в составе данного дистрибутива, отдавая предпочтение наиболее безопасным версиям. Так, вместо telnet используется ssh, а из всех реализаций почтового сервера выбран popa3d. Тщательно подобраны конфигурации серверных пакетов, максимально сужены их привилегии и изолирован доступ к системным ресурсам. Кроме того, в конфигурации по умолчанию пришлось отказаться от потенциально опасных возможностей, оставив администратору право самостоятельно настраивать их защиту исходя из конкретных условий работы серверов.

Также уменьшено число привилегированных программ, которые требуют установки атрибутов SUID/GUID; проверены исходные тексты таких программ, а также библиотек, с которыми они работают. Чтобы сохранить корректность работы сервисов и демонов, были частично изменены механизмы их исполнения и запуска.

Разработчики Castle использовали исправления к ядру, известные как Openwall Kernel patch. Они блокируют легальные, но потенциально опасные операции, такие как исполнение кода в стеке. Эти исправления также ограничивают количество «жестких» ссылок и именованных каналов (named pipe) в каталогах с установленным атрибутом stiky bit. Каждая из перечисленных мер в отдельности не может защитить систему, но в сочетании с RSBAC и другими средствами позволяет достигнуть максимального уровня безопасности.

За рамками Castle

Наиболее известной системой, конкурирующей с RSBAC, является LIDS, в которой используется предусмотренная в POSIX схема маски привилегий. Их раздает привилегированный пользователь — администратор LIDS. Есть также несколько систем (в частности, Medusa), в которых защита реализована по принципу разделения виртуальных пространств для процессов, которые либо совсем не пересекаются, либо правила перехода между которыми зафиксированы. Имеется еще и дистрибутив SELinux, который разработан по заказу американского Агентства национальной безопасности и реализует полную схему распределения полномочий, в которой для каждого пользователя описываются его права доступа для всех ресурсов системы в отдельности.

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

У разработчиков систем защиты, которые, так или иначе, привязываются к системным вызовам ядра, возникла необходимость в универсальном инструменте, который позволял бы встраивать в системные вызовы свои проверки без перекомпиляции всего ядра. Такую технологию предложила компания WX, реализовав в версии ядра Linux 2.5 единый универсальный интерфейс Linux Security Module [4], позволяющий включать дополнительные проверки в системные вызовы, с тем, чтобы разработчики систем безопасности могли адаптировать свои детища под него.

Литература

Классы безопасности компьютерных систем

В 1983 году Министерство обороны США выпустило «Orange Book» — книгу в оранжевой обложке под названием «Критерии оценки достоверных компьютерных систем» (Trusted Computer Systems Evaluation Criteria). За пределами США также появились аналоги «Оранжевой книги»: это руководящие документы Гостехкомиссии, а также «Критерии оценки безопасности информационных технологий» (ITSEC — Information Technology Security Evaluation Criteria), действующие в странах Западной Европы. Новый международный стандарт ISO/IEC 15408 «Единые критерии оценки безопасности в области ИТ» чаще всего называют просто Common Criteria («Единые критерии»).

Критерии, сформулированные в TCSEC, ITSEC и CCITSE, определяют разбиение компьютерных систем на четыре уровня безопасности. Уровень A самый высокий. Далее идет уровень B (в порядке понижения безопасности здесь идут классы B3, B2, B1). Затем наиболее распространенный уровень C (классы C2 и C1). Самый нижний уровень — D. Следуя компромиссу между требованиями безопасности, эффективностью системы и ее ценой, подавляющее большинство компаний стремится сегодня получить сертификат по классу C2.

Класс D. Минимальный уровень безопасности. В этот класс попадают системы, которые были заявлены на сертификацию, но ее не прошли.

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

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

Класс B1. Маркированное обеспечение безопасности. В дополнение к требованиям класса C2 необходимо неформальное описание модели политики безопасности, маркировки данных, а также принудительного управления доступом к поименованным субъектам и объектам.

Класс B2. Структурированная защита. В этом классе систем TCB должна опираться на четко определенную и документированную формальную модель политики безопасности. Действие избирательного и принудительного управления доступом распространяется на все субъекты и объекты в системе. Выявляются тайные каналы. TCB должна четко декомпозироваться на элементы, критичные и некритичные с точки зрения безопасности. Усиливаются механизмы аутентификации. Обеспечивается управление механизмами достоверности в виде поддержки функций системного администратора и оператора. Подразумевается наличие механизмов строгого управления конфигурацией.

Класс B3. Домены безопасности. TCB должна удовлетворять требованиям эталонного механизма мониторинга, который контролирует абсолютно весь доступ субъектов к объектам и при этом быть достаточно компактным, чтобы его можно было проанализировать и оттестировать. Требуется наличие администратора по безопасности. Механизмы аудита расширяются до возможностей оповещения о событиях, критичных по отношению к безопасности. Требуются процедуры восстановления системы. Система крайне устойчива к вторжению.

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

— По материалам статьи Руслана Богатырева «Защищенные операционные системы», «Открытые системы», 2001, № 4.