Одна из главных областей серверного применения системы
Linux является область Web-серверов. Имеются следующие риски в функционировании
системы:
Ошибка в Web-сервере может позволять чтение файлов
находящихся вне его публичной области доступа.
Ошибка в Web-сервере может позволять запись файлов
находящихся вне его публичной области доступа.
Установленные Вебмастером содержащие ошибки сценарии CGI могут получать
доступ к системным файлам нежелательным путём.
Обычными пользователями могут быть установлены без проверки и контроля
Вебмастером сценарии CGI дающие доступ к системным файлам нежелательным
путём.
Все эти риски могут быть устранены или минимизированы
при использовании нашей модели. Для примера мы можем продемонстрироватьпростое решение в котором используются две роли, один объект f/d-типа
и один объект IPC-типа:
Имеются одна роль "Webserver" и один f/d-тип "Web
Document"
Web-сервер, запускаемый от имени нормального пользователя, например
"wwwrun" (Web -сервер )
"wwwrun" получает rc-def-role "Webserver",
таким образом все серверные процессы выполняются с этой ролью
Всем главным каталогам содержащим публичные данные Веб, включая CGI-каталоги,
назначен f/d-тип "Web Document". Этот тип наследуется
всеми подкаталогами и файлами, если они не имеют другого, специально
установленного типа.
Роль "Webserver" получает права только на чтение
и выполнение f/d-типа "Web Document" и права SEARCH
на тип вышеупомянутого дерева каталогов для возможности просмотра
публичных данных.
С такими настройками мы имеем Web-сервер, который не имеет доступа
никуда, кроме своих публичных каталогов и файлов, тем самым решая
проблемы 1 и 2. Между тем, этот Web-сервер также должен иметь возможность
обращения к сети. Следовательно:
Определяем объект IPC-типа "Web IPC"
Предоставляем роли "Webserver" права CREATE и DELETE
на IPC-тип "Web IPC" (если существует проверка сети,
то нам также понадобится READ-WRITE-OPEN)
Устанавливаем IPC-тип создания по умолчанию для роли "Web
server" как "Web IPC"
Теперь мы имеем возможность обслуживать нормальные файлы и выполнять
сценарии CGI с ролью и правами Webserver. Это полностью решает проблемы
3 и 4, однако всё-еще очень ограничивает в действиях. Так что мы идём
далее:
Определяем следующую роль "CGI script"
Даём этой роли теже-самые права, что и "Webserver",
плюс все те права, которые нужны сценариям CGI, например EXECUTE или
CREATE на Web Document или любой другой тип.
По возможности, предупреждаем создание файлов и/или процессов путём
установки для файлов и процессов создаваемых этой ролью значения по
умолчанию no-create.
Попутно уходим от выполнения файлов установкой выполняемого типа для
этой роли по умолчанию в значение no-execute. В таком случае сценарий
не сможет использовать ошибки или особенности других программ.
И наконец, устанавливаем rc-force-role для всех сценариев CGI которым
нужны эти дополнительные права "CGI Script". Они
могут быть либо установлены на каждый файл индивидуально, либо унаследованы
от каталога содержащего сценарии.
Имейте в виду, что индивидуальная установка rc_force_role также
решит проблему 4: Пользователь установивший сценарий CGI выполнит
его либо с ролью "Webserver", которая не может сделать
ничего плохого, либо должен будет явно установить rc-force-role от
"CGI Script" для кого-то обладающего правами MODIFY-ATTRIBUTE
для f/d-типа "Web Document". Этот человек также
может предотвратить вмешательство с этим сценарием установкой его
типа в другое значение.
Если используются различные типы сценариев CGI, то должны быть назначены
дополнительные CGI-роли. При использовании форсированных ролей, сценарии
CGI, которые не могут запускать другие программы, могут быть выполнены
с правами root без риска для безопасности.
В окончательной версии документа мы приведём больше примеров. демонстрирующих
как наша модель способна реализовать защиту интернет-сервера.
