Защита информации - это, пожалуй, самая противоречивая область в компьютерном мире. Сколько людей, столько и мнений о том, как надо защищать данные. Одни говорят: «Давайте уберем из системы все потенциально опасное» - и работают под полупустыми системами типа DOS. Все, конечно, замечательно, но пользователям хочется комфорта. Хочется работать под накрученным редактором типа Word, смотреть Web-странички, переписываться по e-mail и никому не показывать конфиденциальные данные, которые находятся в этой же системе. Хочется ввести электронный документооборот для конфиденциальной информации и обмениваться секретами одним нажатием кнопки. Хочется заполнить сервер самой различной информацией (конфиденциальной и общедоступной), выставить его в Internet и предоставлять своим клиентам конфиденциальные данные, а всем остальным общедоступные. Хочется… программисты и математики садятся писать модели доступа.

Из-за желания учесть все возможные потоки информации модели становятся жутко сложными, программы жутко хитрыми, администраторы идут на повышение квалификации, а пользователь работает и ликует.

Разграничивай и властвуй

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

Очевидно, что все пользователи (включая администратора) должны иметь полномочий ровно столько, сколько необходимо для их нормальной работы в системе. Звучит просто, понятно, и кажется, что решить эту задачу совсем не трудно.

Предположим, что имеется общедоступная область, в которой несколько пользователей работают над файлами. «Нет проблем», - говорит администратор и создает общий каталог. Но пользователям одного отдела не хочется, чтобы в их файлах копались пользователи другого, - появляются группы. А если групп очень много - тут уже не обойтись без списков доступа (Access Control Lists - ACL). А что если нужно, чтобы некоторая программа могла видеть файлы всех пользователей, например, для резервирования, - заводятся еще группы с соответствующими правами. Потом появится желание не давать этой программе некоторые файлы для чтения, а только для запуска… у вас еще не закружилась голова? Конечно, если ограничиться контролем только чтения, запуска и исполнения, то вам хватит ACL, пусть даже путем введения сотни-другой групп.

Но это еще не все. Утечка информации может происходить по вполне законным (с точки зрения вышеописанной модели) каналам. Например, одна или несколько программ могут перебрасывать друг другу некоторую информацию, переводя ее из конфиденциальной области в общедоступную, - значит, надо еще контролировать, чтобы файлы, созданные одной программой, не могли использоваться чужой. Ограничили? А как теперь работать?

Как убить root’а?

Добавим масла в огонь. У нас есть всемогущий администратор. Мы дали ему исключительные возможности по расстановке прав и, как следствие, исключительный доступ к данным. В случае несанкционированного доступа взломщику достаточно получить права администратора и… плакали ваши секреты. C другой стороны, именно администратор должен контролировать доступ пользователя к файлам, критичным для функционирования системы. Разумное решение - сделать два вида прав: для системных данных и для конфиденциальных данных. А кому дать возможность контролировать доступ к конфиденциальным данным? Пользователю? Круг замкнулся.

Большинство перечисленных вопросов легко и даже элегантно решаются в свободной системе разграничения доступа Rule Set Based Access Control (RSBAC) for Linux. Появившись в 1996 году как дипломная работа немецкого студента Амона Отта (Amon Ott), RSBAC претерпела значительные изменения, став серьезной системой, конкурирующей с другими популярными проектами. Система представляет собой достаточно большой патч (заплатку) к стандартному ядру Linux и, благодаря хорошо продуманной архитектуре, легко переносится на все более новые версии ядра.

Начнем с администратора. Теперь больше нет всемогущего и бесконтрольного «суперпользователя» (root). Зато имеются уже два класса выделенных пользователей: администратор системы и администратор безопасности. Последний обладает полномочиями обычного пользователя, но может также вводить дополнительные, доступные только ему, права на файлы. Как все это работает?

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

Рассмотрим RSBAC с точки зрения предоставляемых средств защиты. Система базируется на архитектуре Generalized Framework for Access Control (GFAC, см. рисунок), что позволяет одновременно использовать разные модели доступа. Модули, реализующие те или иные модели, независимы друг от друга, за исключением базового модуля AUTH. Администратор безопасности может активизировать или временно отключать неиспользуемые в данный момент модули. Решение о доступе принимается как совокупное после опроса всех активных модулей.

Основные предлагаемые модули следующие.

• AUTH (Authentification) - головной модуль. Следит за сменой владельца у процессов. В обычной среде процессы, запускаемые от имени администратора, могут менять владельца, как им заблагорассудится, в результате администратор может менять владельца на любого пользователя без введения пароля, что неблагоприятно сказывается на конфиденциальности информации. Теперь же процессы могут менять владельца только на конкретных пользователей. Оставлена возможность некоторым процессам вести себя, как раньше, в силу своих особенностей (например, login). Также можно упорядочить смену владельца при помощи некоторой программы-посредника - при успешной проверке она будет раздавать разрешения на смену владельца, при этом сама не будет иметь возможности на смену.

• MAC (Mandatory Access Control) - мандатный доступ. Это слишком сложная модель, чтобы уместить ее в рамках статьи и чтобы читатель не заснул ¹, поэтому скажу кратко: каждому объекту и субъекту назначается гриф секретности («несекретно», «секретно», «совершенно секретно» и т. д.) и уровень доступа соответственно. Пользователь получает доступ к объекту, только если его уровень допуска позволяет это сделать. В модель также заложены правила, предотвращающие понижение уровня конфиденциальности информации (помните о программах, передающих друг другу данные?). Вся сложность этой и некоторых последующих моделей связана с желанием и жить комфортно, и в то же время засекретить построже.

• FF (File Flags) - очень простая модель. Позволяет быстро и легко настроить права на целые древа каталогов (только чтение, только запуск, только чтение и запуск…) и при необходимости отключать наследование прав на определенные файлы (внутри каталога, настроенного только на чтение, могут быть файлы, в которые нужно обеспечить запись). Очень удобна эта модель для создания замкнутой программной среды, когда все исполняемые программы и их библиотеки не подлежат изменению, а пользователи не могут запускать посторонние программы из своих домашних каталогов. Если понадобится обновить программное обеспечение, администратор безопасности может временно снять ограничения, а так как количество выставляемых прав очень невелико, сделает он это достаточно быстро.

• ACL (Access Control Lists) - обычные списки доступа. Но обычные до того момента, пока вы не ознакомитесь с ними подробнее. Количество возможных прав доступа (больше тридцати) удовлетворит самого искушенного администратора, а помимо возможности задавать права для пользователя и ACL-группы можно задать права для RC-ролей, о которых будет сказано чуть ниже.

• RC (Role Compatibility) - ролевая модель, в которой определяются роли и типы, а затем определяется, что может делать та или иная роль с тем или иным типом. Таким образом создается абстрактная модель, которая затем привязывается к реальным пользователям, программам и файлам. Независимость модели от реальных субъектов и объектов позволяет производить мгновенную перенастройку политики безопасности быстрым перепривязыванием ролей и/или типов. Кроме того, это очень удобно для создания готовых решений (например, распределения ролей и типов для защиты содержимого страниц Web-узла). Интересной особенностью является возможность запускать программы с ролью, отличной от роли пользователя, производящего запуск. В результате можно, например, произвести такие настройки, что прямой доступ к диску будут иметь только разрешенные программы, а все остальные пользователи системы (включая администратора) будут лишены такой возможности.

• REG (Module Registration) - это, собственно, уже не модель, а подсистема, позволяющая подключать на лету модули собственного изготовления. Вы можете описать свою модель доступа, подключить ее и использовать.

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

Для обслуживания такого количества моделей требуется соответствующее количество прав, а последние где-то надо хранить. RSBAC не хранит данные непосредственно в файловой системе, что делает его не зависимым от конкретной реализации и усиливает переносимость. Для хранения используется своя база. Она размещается на каждой смонтированной файловой системе в каталоге /rsbac, доступа к которому не имеет никто, кроме ядра. Важно, что изменения вступают в силу немедленно, без перезагрузки системы, а при крайней необходимости можно менять права прямо у работающих процессов.

Протоколирование поставлено на самом высоком уровне - возможно отслеживание конкретного вида запроса к файлу (чтение, запись), а также конкретных запросов от интересующих пользователей и программ.

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

Немаловажно, что все это реализуется при минимальных потерях в части производительности: проведенные тесты свидетельствуют, что ее деградация не превышает 5,8% для ядра с RSBAC и 7% - для ядра с RSBAC и включенными модулями RC, ACL, AUTH, FF (по сравнению с «чистым» ядром). Соответствующие усредненные значения - 3,3% и 3,6% соответственно.

ALT Linux Castle

Первым дистрибутивом, поддерживающим RSBAC «из коробки», является ALT Linux Castle, представленный на момент написания статьи бета-версией. Во время инсталляции создается учетная запись администратора безопасности, и при первом запуске ядра с RSBAC задается базовая конфигурация защиты: все ключевые каталоги с программами и библиотеками переводятся в режим «только для запуска» либо «только для чтения»; файлы конфигурации, ответственные за добавление пользователей, изменение конфигурации файловой системы и загрузчиков также доступны только для чтения; доступ в каталог /home, где размещены домашние каталоги пользователей, открыт только для владельцев и администратора безопасности; домашний каталог администратора безопасности вынесен из /home, закрыт для всех, кроме владельца, и при необходимости в нем может быть размещена собственная доверенная программная среда.

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

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

В направлении разграничения прав доступа как неотъемлемая часть дистрибутива реализована технология создания и поддержки так называемых chrooted environments - изолированных сред выполнения, в которых работают все основные службы. Влияние программ, работающих в таких средах, на другие программы и систему в целом минимально; даже в случае обнаружения уязвимости программа, запущенная в такой среде, не представляет угрозы для безопасности остальных компонентов системы.

[i39652]