3.3. Сравнение rsbac и seLinux.

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

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

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

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

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

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

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

По поводу рассмотренных проектов можно сказать следующее. Open-wall является достаточно хорошим набором патчей к ядру ОС, но развивается достаточно медленно.

PaX предназначен исключительно для противостояния атакам, связанным с переполнением буфера. Следовательно, PaX должен использоваться совместно с другими механизмами обеспечения безопасности ОС.

Medusa также как Openwall очень медленно развивается, но может применяться для систем с ядром 2.4 и ниже.

Grsecurity сочетает в себе набор патчей и мандатную модель на основе идентификатора (IBAC). Но в связи с прекращением финансирования этого проекта неизвестно, будет ли он развиваться в дальнейшем.

LIDS является довольно интересным проектом, в котором широко применяются capabilities. Но в России данная система не распространена.

Наиболее предпочтительными представляются программные комплексы RSBAC и SELinux, которые являются наиболее мощными и гибкими из применяемых на данный момент.