Д. С. Кулябов > Стандарты информационной безопасности

• Default Process Chown Type — подтип процесса после смены вла­дельца (setuid);
  

• Default Process Execute Type — подтип процесса после запуска;
  

• Default IPC Create Type — подтип новых IPC каналов, семафоров и т.д.
  

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

3.3.1.8. Модуль FF

При помощи данного модуля можно назначать атрибуты целым дере­вьям каталогов. Например, можно назначить флаг "read_only"(только для чтения) для каталогов /bin, /sbin, /usr/bin, /usr/sbin.

3.3.1.9. Functional Control (FC)

Простейшая ролевая модель, которая назначает каждому пользовате­лю роль, например главный пользователь, офицер безопасности или си­стемный администратор. Каждый объект получает категорию, например, главный, секретный или системный объект.

FC может быть полностью выражен RC-моделью.

3.3.1.10. Simone Fischer-Hubner’s Privacy Model (PM)

Эта модель была представлена на 17-ой Национальной Конференции Компьютерной Безопасности в Балтиморе, США, в 1994 году ее разра­ботчиком Simone Fischer-Hubner. Это следствие из правил Федерального Немецкого Закона о Секретности и директивы Европейского Союза о без­опасности.

Модель сфокусирована на безопасности. Конфиденциальность, целост­ность и доступность представлены для личных данных и процедур по определению необходимых доступов.

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

Эта модель может быть использована для хранения и обработки персо­нальных данных. Для защиты системных данных без администрирования наверху, рассматривая их как персональные данные, должна использо­ваться другая модель, например FC, RC или ACL.

3.3.1.11. Malware Scan (MS)

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

обычные пользователи — с ролью usr_r, а для системных администраторов зарезервирована роль sysadm_r.

3.3.2.3. Домены

Для каждой роли в политике безопасности задается набор доменов, в которых допускается работа с этой ролью. Всем пользовательским ролям назначается стартовый домен: 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-апплеты, сценарии " onclick="return false">
3.3.2.4. Политика безопасности

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

все критичные операции не должны производиться в одиночку. Действи­тельно, возможно построение системы, в которой нового пользователя по-прежнему заводит 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 операционную систему общего назначения, которая автоматически обеспечит надежность, безопасность, выполнение принципа минимальных привилегий [25] и другие свойства любым запускаемым в ней приложе­ниям. Type Enforcement — это механизм, позволяющий произвести инте-