Linux на защите информации

Статья посвящена проблеме построения защищенных операционных систем, «свободных» от недостатков в обеспечении безопасности, присущих традиционным Unix-подобным системам. В качестве основы предлагается использовать открытые компоненты, а именно: проекты RSBAC и Security-Enhanced Linux, ориентированные на ядро Linux.

Cегодня многие индивидуалы и организации остановили свой выбор на операционной системе Linux, взяв ее на вооружение в качестве основной платформы. Причем, если раньше эта ОС использовалась преимущественно в качестве основы для построения недорогих маршрутизаторов, Web-серверов и почтовых серверов, то сегодня имеется целый ряд более серьезных задач, которые удобно решать на ее базе: серверы баз данных и доступа, серверы приложений и полнофункциональные межсетевые экраны. Благодаря высокой устойчивости ОС Linux ей можно смело поручать длительные вычислительные задачи, например часть компьютерных спецэффектов в фильме «Титаник» считалась именно под управлением Linux. Система находит применение и в качестве встроенной ОС, например, в Web-камерах Axis.

Как известно, Linux — это клон Unix, семейства операционных систем, объединенных общей идеологией. Первые Unix-системы создавались исключительно как средство совместного ведения проектов научными коллективами университетов и ее разработчики не придавали особого значения вопросам безопасности и защиты информации. Во всяком случае, эти вопросы точно стояли не на первом месте. Это привело к тому, что ни одну из классических Unix-систем нельзя сегодня назвать по-настоящему безопасной. На протяжении всей истории существования ОС ее постоянно взламывают, портят, увечат, крадут и искажают. Создается иллюзия, что это самая незащищенная (и поэтому самая любимая хакерами) из всех операционных систем. Однако стоит вспомнить, что этой операционной системе уже более 30 лет, в то время как другие системы еще пребывают в младенческом возрасте, особенно операционные системы для ПК. Немаловажно и то, что Unix с самого рождения обладает сетевыми функциями и является сегодня самой распространенной системой в Internet.

Относительно защищенный вариант Unix-системы можно построить на базе ее штатных средств и для большинства применений это будет вполне адекватный уровень безопасности. Этот процесс достаточно подробно описан во многих документах: начиная от классических рекомендаций UNIX Configuration Guidelines (www.cert.org) и заканчивая циклом публикаций Ланса Спитцнера, посвященных «усилению» различных ОС: Windows NT, Solaris, Linux [1]. В Cети можно найти также и русский перевод документа Linux Security HOWTO [2]. Однако в самой идеологии построения Unix имеется ряд фундаментальных изъянов, которые невозможно преодолеть только грамотным администрированием.

Фактически, в Unix предполагается всего два варианта статуса пользователя: обычный и суперпользователь (root), что сразу порождает две проблемы. Первая проблема заключается в том, что root никому не подконтролен: он может изменить любую настройку, имеет доступ абсолютно ко всем объектам в файловой системе, может стереть или модифицировать любые данные и записи в журналах регистрации. Такая «концентрация власти», конечно же, неприемлема для защищенной системы. Вторая проблема связана с необходимостью изменения текущего уровня привилегий пользователя для выполнения некоторых действий (например, для смены пароля пользователю требуется временное разрешение на запись в файл /etc/shadow или аналогичный). Традиционно это достигалось путем установки флага SUID (или SGID) на файлы исполняемых модулей программ, в результате чего, порождаемый при запуске такого файла процесс, приобретает не права запустившего его пользователя, а права владельца файла. Нет необходимости говорить, к чему может привести даже небольшая ошибка в программе с установленным флагом SUID и владельцем root. А писать полностью свободные от ошибок программы человек еще не научился — достаточно посмотреть на BugTrack (www.securityfocus.com).

Реализованная в Unix модель разграничения доступа дискретна — права доступа субъектов (пользователей, процессов) к объектам (файлам, каталогам и т.п.) задаются явно, в матричной форме. На практике же часто возникает необходимость в реализации принудительной модели, при которой права доступа субъекта к объекту определяются уровнем субъекта и классом объекта, либо комбинированной модели, включающей в себя принудительную и доступ на основе списков управления доступом. Причем, если в других ОС, использующих дискретную модель (например, Novell NetWare), необходимого разграничения достичь можно, то в Unix реализация некоторых требований по разграничению может оказаться попросту невозможной. Это связано с тем, что в Unix права доступа задаются всего для трех категорий субъектов: владельца файла, ассоциированной с файлом группы и всех прочих. В частности, невозможно задать разные права доступа к файлу для менеджера проекта, начальника отдела, менеджера направления и сотрудника, непосредственно работающего с файлом, закрыв доступ всем остальным пользователям.

Ряд других проблем (например, передача паролей и других данных в открытом виде по сети при взаимодействии по различным протоколам) решаются широким кругом стандартных средств (ssh, IPsec и т.п.) и в большинстве своем не являются Unix-специфичными.

В качестве примеров решения приведенных проблем с организацией защиты предлагается рассмотреть две системы: RSBAC (Rule Set Based Access Control) и Security-Enhanced Linux, позволяющие построить защищенную систему на базе ядра Linux.

RSBAC

RSBAC — это надстройка над ядром Linux и комплект утилит управления, позволяющие создать на базе любого дистрибутива Linux защищенную систему. Одной из целей создания RSBAC, по заявлению авторов, является выполнение всех требований B1 по классификации так называемой «Оранжевой Книги» (хотя набор этих требований уже несколько устарел). К этой цели следует относиться с известной долей иронии не только вследствие архаизма «радужной» серии, но и из-за ставшей крылатой фразой, относящейся к сертификации Windows NT 3.51 по классу C2: «Любой вариант Linux можно сертифицировать по классу B1. С вынутым шнуром питания» — настолько серьезны были дополнительные условия, при которых выполнялись требования сертификации NT 3.51. В частности, в соответствии с документом [5], должны были быть отключены подсистемы OS/2 и POSIX, а самое главное — средства работы с сетью.

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

• типа запрашиваемого доступа (чтение, запись, исполнение);
• субъекта доступа;
• атрибутов субъекта доступа;
• объекта доступа;
• атрибутов объекта доступа.

Функционально RSBAC состоит из нескольких модулей, а центральный компонент принимает комплексное решение, основываясь на результатах, возвращаемых каждым из активных в данный момент модулей (какие модули задействовать и в каком объеме определяется на этапе настройки системы). Начиная с версии 1.1.0, в RSBAC включены следующие модули, реализующие различные функции и модели управления доступом:

• MAC (Mandatory Access Control). Модуль MAC обеспечивает принудительное управление доступом на основе классической модели Белла-Лападулы [4], цель которой — не допустить перетекания информации из более секретных объектов в менее секретные.
• FC (Functional Control). Данный модуль реализует простую ролевую модель, в которой доступ к системной информации разрешен только администраторам системы, а доступ к информации, связанной с безопасностью, разрешен только офицерам безопасности.
• SIM (Security Information Modification). Модуль SIM обеспечивает возможность модификации данных, помеченных как «security information», только администраторами безопасности.
• PM (Privacy Model). Данный модуль реализует модель безопасности, направленную на обеспечение приватности личных данных. Основная идея [5] состоит в том, чтобы пользователь мог получить доступ к персональным данным только, если они ему необходимы для выполнения текущей задачи и если он авторизован на ее выполнение. Кроме того, цели выполнения текущей задачи должны совпадать с целями, для которых эти данные собраны, либо должно быть получено согласие субъекта этих данных.
• MS (Malware Scan). Этот модуль обеспечивает сканирование всех файлов на наличие вредоносного кода. Дополнительно, данный модуль может контролировать все запросы на чтение файлов и соединений TCP/UDP. В текущей версии модуль умеет обнаруживать вирусы Bliss.A, Bliss.B, VHP-648, Israeli, Eddie2, Dark Avenger и 1704C. Конечно, это немного, и вирусы не самые новые и опасные, но это только начало.
• FF (File Flags). Модуль FF предоставляет механизм установки и проверки флагов на файлы и каталоги. Причем, модифицировать флаги разрешено только офицерам безопасности системы. Пока поддерживаются флаги execute_only (для файлов), read_only (для файлов и каталогов), search_only (для каталогов), secure_delete (для файлов), no_execute (для файлов) и add_inherited (для файлов и каталогов). Смысл флагов ясен из их названия и, конечно, знаком тем, кто пользовался механизмами атрибутов и прав в файловой системе Novell NetWare.
• RC (Role Compatibility). Данный модуль определяет 64 роли и 64 типа для каждого вида объекта. Виды объектов могут быть следующими: file, dir, dev, ipc (interprocess communication), scd (system control data), process. Для каждой роли отношение к различным типам и другим ролям настраивается индивидуально, в зависимости от вида запроса. Используя данный модуль, можно настроить разделение обязанностей между администраторами, избежав при этом назначения избыточных прав.
• AUTH (Authorization Enforcement). У этого модуля задача очень конкретная — контролировать запросы процессов на смену текущего идентификатора пользователя. Под контролем данного модуля программе недостаточно просто иметь установленный бит suid, ей необходим специальный атрибут, разрешающий такое действие. Причем, он может быть, как глобальным (uid может быть сменен на любой), так и списочным (процесс может сменить свой uid только на определенные).
• ACL (Access Control List). ACL — самый «прикладной» модуль из данного списка. Он определяет, какие субъекты могут получать доступ к данному объекту, и какие типы запросов им разрешены. Субъектом доступа может быть как простой пользователь, так и роль RC и/или группа ACL. Объекты группируются по видам, но каждый имеет собственный список ACL. Если права доступа к объекту не заданы явно, они наследуются от родительского объекта с учетом маски наследования прав. Эффективные права доступа субъекта к объекту складываются из прав, полученных непосредственно, и прав, полученных через назначение на роль или членство в группе ACL. Такой подход к назначению прав покажется очень знакомым специалистам, работавшим с NetWare. Более того, утилита управления acl_grant имеет режим совместимости по названиям прав с аналогичной утилитой из NetWare.

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

RSBAC дает возможность избавить систему от общих недостатков Unix. Появление должности «офицер безопасности» (security officer, security administrator) решает проблему не подконтрольности основного администратора системы, а категории «офицер по защите данных» (data protection officer) децентрализует администрирование, позволяя практически реализовать принцип «четырех глаз», в соответствии с которым все критичные операции не должны производиться в одиночку. Действительно, возможно построение системы, в которой нового пользователя по-прежнему заводит root, однако, его уровень безопасности и права доступа к ресурсам задаются офицером безопасности и офицером по защите данных.

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

RSBAC можно интегрировать с любым дистрибутивом Linux, необходимо лишь внести соответствующие исправления в исходные тексты ядра системы. Эта процедура осуществляется при помощи стандартной утилиты patch и прилагаемого файла-«заплатки», который предлагается для разных версий ядра. После этого происходит его обычная настройка (make config, make menuconfig и т.п.), при этом в настройке появляется несколько новых пунктов. После загрузки ядра (а их рекомендуется собрать два: одно «боевое», а другое — отладочное, позволяющее производить настройки свойств RSBAC, но с отключенными «сторожевыми» функциями) настройка системы производится при помощи прилагаемых утилит администрирования. Разработчики системы поступили очень мудро — настройка возможна как при помощи иерархической системы меню, так и при помощи командной строки с параметрами. Особо следует отметить, что меню и страницы руководства представлены как на английском, так и на русском языках. Система снабжена документацией и подборкой теоретических материалов, где описаны все используемые модели защиты. С основного сервера проекта RSBAC есть ссылка на дополнительные материалы, среди которых имеется прекрасная статья [6] с пошаговыми инструкциями по ознакомлению с системой, позволяющая благополучно миновать многие «узкие» места.

Security-Enhanced Linux

Вторая система — Security-Enhanced Linux имеет такое же назначение, как RSBAC и также представляет собой дополнения к ядру и набор утилит. Обе системы доступны под лицензией GPL, однако, разработка Security Enhanced Linux продвигается Агентством национальной безопасности США. Security Enhanced Linux «моложе» RSBAC — ее релиз впервые был представлен в декабре 2000 года [7]. К сожалению, почти сразу же после первого выпуска системы была найдена серьезная брешь в ее безопасности — ошибка переполнение буфера, причем непосредственно в securitylib, что указывает на некоторую поспешность выпуска релиза [8]. Security-Enhanced Linux обеспечивает гибкую архитектуру принудительного контроля доступа (flexible mandatory access control architecture — FLASK) [9], использующую развитый язык описания конфигураций политики безопасности. С использованием этого языка описаний разработана конфигурация системы, реализующая идеологию Type Enforcement.

Что же такое Type Enforcement? Самый короткий ответ на этот вопрос приведен в [13]: «Это матрица доступа.., организованная для эффективности в классы эквивалентности». Действительно, обычная матрица доступа представляет собой двухмерную таблицу, по одной оси которой располагаются субъекты доступа (активные именованные сущности — процессы, пользователи), по другой — объекты доступа (пассивные сущности — файлы, каталоги, устройства и другие ресурсы), а в ячейках на пересечении указываются операции, которые субъект может выполнять над объектом. В системе с большим количеством сущностей построить такую матрицу может оказаться попросту невозможным. Но в этом и нет необходимости: многие объекты схожи по своим свойствам, а функции многих субъектов совпадают, что позволяет объединить их в классы эквивалентности и строить матрицу для классов, проведя, фактически, типизацию сущностей.

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

В политике безопасности также определен набор ролей. Для пользователей первичная установка роли происходит в процедуре регистрации (login), а переключение роли — при помощи команды newrole (в некотором роде аналог su). Системные процессы работают с ролью system_r, обычные пользователи — с ролью usr_r, а для системных администраторов зарезервирована роль sysadm_r.

Для каждой роли в политике безопасности задается набор доменов, в которых допускается работа с этой ролью. Всем пользовательским ролям назначается стартовый домен: user_t для роли user_r и sysadm_t для роли sysadm_r. По мере выполнения программ, запускаемых из стартовой оболочки shell, может происходить автоматическое перемещение в другие домены для обеспечения изменения привилегий. Выбор домена, в который должно быть произведено перемещение осуществляется не только исходя из типа запускаемой программы, но и с учетом текущего домена. В частности, при запуске браузера Netscape обычным пользователем (текущий домен user_t), произойдет перемещение в домен user_netscape_t, а при запуске этой же программы администратором (текущий домен sysadm_t) перемещение произойдет в другой домен — sysadm_netscape_t. Такой подход не позволит программе выполнить потенциально опасные действия — соответствующий домен серьезно ограничит права администратора. В обычных дистрибутивах Linux в случае с браузером Netscape проблема решалась проще — в настройке по умолчанию программа просто не запускалась с правами root.

Для администраторов в Security-Enhanced Linux заданы достаточно жесткие ограничения. В частности, нельзя зайти в систему удаленно — при необходимости такой процедуры необходимо сначала произвести вход обычным пользователем, а потом переключиться на административную роль при помощи команды newrole, производящей дополнительную аутентификацию. Впрочем, и в большинстве современных Unix-подобных систем администратору также запрещен удаленный вход и для этой цели используется команда su.

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

Политика безопасности должна контролировать различные формы прямого доступа к данным, поэтому в ней определяются различные типы для устройств памяти ядра (kernel memory device), дисковых устройств, специальных файлов в каталоге /proc, а также различные домены для процессов, которым необходим доступ к этим ресурсам. Обеспечение целостности ядра достигается определением различных типов для загрузочных файлов, объектных файлов подключаемых модулей, утилит для работы с модулями и файлов конфигурации модулей. Соответствующим процессам, которым требуется право записи в эти файлы, назначаются специальные домены.

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

Политика безопасности уделяет особое внимание тщательному разделению процессов по привилегиям и защиту привилегированных процессов от выполнения ошибочного или опасного кода. Путем установки атрибута executable только на необходимые для исполнения привилегированным процессом программы, политика безопасности может достичь того, что при входе в привилегированный домен процессу будет позволено выполнение только стартовой программы для данного домена, динамического компоновщика и системных разделяемых библиотек. Администратор ограничен выполнением системных программ и программ, созданных им самим — выполнение программ, созданных другими пользователями запрещено. Более того, система минимизирует взаимодействие между обычными пользовательскими процессами и системными. Только системным процессам и администраторам разрешен доступ к записям в procfs, относящимся к другим доменам; ограничено использование вызова ptrace по отношению к другим процессам и доставка сигналов между разными доменами. При использовании файловой системы также приняты дополнительные меры предосторожности: домашние каталоги администраторов и обычных пользователей отнесены к разным типам; создаваемым в каталогах общего пользования (/tmp и др.) файлам также присваиваются разные типы, в зависимости от создавшего их домена.

По сравнению с RSBAC система Security-Enhanced Linux менее гибкая, зато имеет очень хорошую предопределенную политику безопасности. Ее сложно применить для «небольшого усиления» стандартного дистрибутива Linux — настройка достаточно сложна и невозможна без изучения специального языка конфигурации. Но это не недостатки, а скорее следствия целей создания системы. В [13] отмечается, что не стоит пытаться создать на базе идеологии Type Enforcement операционную систему общего назначения, которая автоматически обеспечит надежность, безопасность и другие свойства любым запускаемым в ней приложениям. Type Enforcement — это механизм, позволяющий произвести интеграцию приложений и менеджера ресурсов, сведя при этом к минимуму присущие им недостатки. Это средство построения специализированных защищенных систем, в которых все лишние функции убраны, а поведение оставленных жестко определено матрицей Type Enforcement.

Заключение

Рассмотренные системы не единственны в своем классе — большинство защищенных решений делается на базе открытых систем. Среди них — проекты Medusa (medusa.fornax.sk), тесно сотрудничающий с RSBAC, и LinuxIDS (www.lids.org). Из отечественных в первую очередь следует вспомнить «легендарную» МСВС, сделанную на базе Linux для Министерства обороны в 1997 году и сертифицированную Гостехкомиссией, в компетенцию которой входит сертификация по требованиям безопасности автоматизированных систем. Критерии классификации систем отличаются от американской «Оранжевой Книги» и изложены в Руководящем Документе «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации».

Если выйти за рамки Linux и обратиться к другим Unix-подобным системам с открытым исходным кодом, то следует упомянуть разработанный МО ПНИЭИ криптографический маршрутизатор «Шип», построенный на базе FreeBSD. Несколько особняком стоит проект, разрабатываемый Специализированным центром защиты информации Санкт-Петербургского государственного технического университета — ОС «Феникс» (см. статью в этом выпуске журнала), которая явно не происходит от какой-либо разработки Free Software Foundation, но унаследовала, по словам разработчиков, лучшие особенности микроядер других ОС.

Литература

Владислав Мяснянкин (hugevlad@yahoo.com) — независимый эксперт

Модель защиты личных данных