По мере роста популярности Linux пользователи, особенно из государственного сектора, все настойчивее требовали от разработчиков получения для этой операционной системы сертификата на защиту. Ее коммерческие конкуренты уже получили такой сертификат, и свободно распространяемой Linux он был остро необходим. Проанализировав ситуацию, корпорация IBM решила финансировать сертификацию Linux на соответствие стандарту Common Criteria.

Международная группа экспертов разработала рекомендации Common Criteria для оценки функций защиты компьютерных продуктов. В 1999 году Международная организация по стандартам (International Organization for Standards, ISO) одобрила Common Criteria как стандарт ISO 15408.1. Правительства двух десятков стран, в том числе США, Канады, Германии, Франции, Японии и Великобритании, официально приняли Common Criteria. С июля 2002 года США требуют, чтобы все ИТ-продукты, используемые при обработке критически важных данных в государственных учреждениях страны, имели сертификат Common Criteria или Federal Information Processing Standard (FIPS) 140 на средства шифрования.

Насколько известно, до сего времени ни одна из свободно распространяемых программ не имела сертификата Common Criteria. Кое-кто считал, что свободно распространяемое программное обеспечение вообще не может получить такой сертификат, однако IBM и atsec на примере ОС Linux доказали обратное. Кроме того, бытует мнение, что для получения сертификата на защиту требуется много времени — зачастую годы. В отношении Linux это удалось сделать всего за четыре месяца. Рассмотрим, как проходила сертификация, и проанализируем некоторые аспекты, касающиеся исходных текстов Linux.

Защита свободно распространяемого кода

Лицензия на свободно распространяемую программу позволяет использовать ее с любой целью, изучать и изменять, а также распространять копии исходной программы и ее модификации без выплат авторских гонораров разработчикам. Два наиболее известных примера свободно распространяемых программных систем — операционная система Linux и Web-сервер Apache. И хотя мы будем говорить преимущественно о Linux, большая часть описываемых стратегий применима к любым свободно распространяемым программам.

Linux — член большого семейства Unix-подобных операционных систем, созданных компаниями A&T, Digital Equipment, IBM, Hewlett-Packard и Sun Microsystems. Однако, в отличие от остальных систем, Linux не является коммерческой операционной системой, и полного контроля над ней не имеет ни один производитель. Линус Торвальдс, разработавший Linux в 1991 году, предполагал, что эта ОС будет работать на IBM PC с процессорами Intel, но сейчас она используется практически на всех аппаратных платформах. Кроме того, появление Linux стимулировало разработку огромного числа свободно распространяемых программ, в том числе MySQL, Python, Open LDAP и предлагаемых в исходных текстах реализаций Kerberos.

С начала разработки свободно распространяемых решений ведутся дебаты о том, могут ли они обеспечить более надежную защиту, чем коммерческие системы. Пока компьютерное сообщество не пришло к определенным выводам. С одной стороны, свободно распространяемое программное обеспечение дает равные условия как злоумышленникам, так и обороняющимся от них [2], с другой — открывает последним доступ к методикам защиты и знаниям, которые редко можно получить при использовании коммерческих программных продуктов. Большинство программистов, участвующих в движении Open Source, принимают дополнительные меры для защиты своего кода, поскольку в случае недостаточной безопасности программы они рискуют собственной репутацией. Кроме того, свободно распространяемый код анализируется и проверяется всем сообществом.

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

Процесс сертификации

Common Criteria определяет несколько уровней сертификации, от Evaluation Assurance Level 1, EAL1 (самый низкий уровень, требующий лишь минимального набора документации и тестирования функций защиты) до EAL7 (наиболее высокий уровень, требующий формально описанных функций защиты, тщательного тестирования всех аспектов этих функций и детального анализа уязвимостей). Многие коммерческие конкуренты Linux прошли сертификацию EAL4.

IBM и atsec первоначально планировали провести для Linux именно сертификацию EAL4. Этот уровень защиты технически достижим, но для получения соответствующего сертификата потребовалось бы около трех лет. С учетом рыночной ситуации была поставлена цель получить сертификат на достойный уровень защиты достаточно быстро (примерно за шесть месяцев), поэтому было решено остановиться на сертификации EAL3.

Однако, например, для информационных систем страхования жизни необходим уровень защиты не менее EAL3, а свободно распространяемому коду трудно соответствовать таким требованиям с первого же раза. Кроме того, создание существенных дополнений к Linux для поддержки функций защиты могло еще больше увеличить срок получения сертификата, поэтому IBM и atsec решили сертифицировать Linux в ее нынешнем виде.

В результате для начала было намечено получить сертификат уровня EAL2 для SUSE Linux Enterprise Server 8, популярной разновидности Linux. Надо сказать, сейчас удалось добиться для SUSE Linux и Red Hat Linux защиты на уровне EAL3 с полным соответствием профилю управляемой защиты доступа [3]. Возможно и дальнейшее совершенствование Linux для обеспечения более высоких уровней гарантии и выполнения требований более сложных профилей защиты.

Анализ и требования EAL2

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

  • независимое тестирование функций защиты;
  • свидетельство тестирования ОС разработчиком на основе функциональной спецификации;
  • избранное независимое подтверждение результатов такого тестирования;
  • тщательный функциональный анализ;
  • свидетельства поиска разработчиком уязвимостей;
  • проверка соответствия функциональной спецификации, высокоуровневой архитектуры и документации реальному поведению системы;
  • проверка списка конфигураций для выбранной версии Linux (в данном случае SUSE Linux Enterprise Server 8);
  • свидетельство защищенных процедур доставки дистрибутива.

Требования EAL2 распределяются по нескольким группам.

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

Описание защиты

Common Criteria позволяет выбрать функции защиты для сертификации. Описание защиты (security target) — это документ, который детально определяет функции защиты. Он должен подтвердить, что набор выбранных функций полезен и согласован, описать угрозы при некорректном использовании этих функций и требования к защите операционной среды (например, физическая защита и доверие к пользователям, администрирующим систему).

При первой экспертизе описание защиты содержало следующие функции.

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

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

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

Управление защитой. Определяет функции пользователей с полномочиями root и будет применяться для администрирования сервера Linux. Описание защиты определяет две роли: системный администратор и обычный пользователь. Системный администратор — это пользователь с полномочиями root (в оцениваемой конфигурации — доверенный пользователь). Прямая регистрация с такими полномочиями запрещена. Другие пользователи являются обычными.

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

При экспертизе использовались системы IBM xSeries с Intel Pentium 4 и Xeon, как однопроцессорные, так и многопроцессорные. При последующих экспертизах будет рассмотрено больше аппаратных платформ.

В состав оцениваемой конфигурации входят несколько базовых сетевых сервисов, выполняющихся как доверительные процессы (процессы с привилегиями root). Кроме того, поддерживаются другие сетевые протоколы, обслуживаемые недоверительными процессами на непривилегированных портах. Например, оцениваемая конфигурация дает возможность запускать Web-сервер как недоверительный процесс на портах с номерами больше 1024. В описании защиты (www.bsi.de/zertifiz/ zert/reporte/0216b.pdf) функции обеспечения безопасности определены более детально.

При подготовке описания защиты по мере возможности использовался профайл защиты контроля над доступом CAPP [3] для указания угроз, которым может противостоять защита, правил, которым необходимо следовать, предположений о среде и требований к ней, а также к самим функциям защиты. Это связано со стремлением определить, какие из функций, необходимых для полного соответствия профайлу защиты, были пропущены, и восполнить такой пробел. CAPP — стандарт на требования к защите коммерческих операционных систем, установленный правительством США и служащий основой для экспертизы других операционных систем.

Требуемая документация и анализ

Common Criteria требует набора архитектурной документации и руководств, на основе которых выполняется анализ. Первый документ, функциональная спецификация, определяет внешние интерфейсы функций защиты. Функциональная спецификация для Linux состоит из следующих частей:

  • системные вызовы ядра;
  • процессы или программы, выполняющиеся с привилегиями root (это программы, запущенные как демон с привилегиями root, либо программы с установленным битом setuid, владельцем которых является процесс с привилегиями root и которые выполняются пользователями без привилегий root);
  • конфигурационные файлы, влияющие на функции защиты.

В мире Unix руководства (man pages) описывают внешние интерфейсы системных вызовов и программ, а также конфигурационные файлы. При сравнении списка системных вызовов в SUSE Linux Enterprise Server 8 (использует стандартную версию ядра 2.4.19) с существующими руководствами выяснилось, что эти руководства для некоторых конфигурационных файлов описывали не все имеющиеся параметры. Для восполнения пробела были разработаны недостающие руководства для системных вызовов. Кроме того, усовершенствованы некоторые из руководств для критически важных конфигурационных файлов.

Вдобавок Common Criteria требует документацию на архитектуру высокого уровня, описывающую реализацию функций защиты. Хотя работе ядра посвящено немало документов и книг, очень немногие из них подробно останавливаются на реализации аспектов защиты, таких как списки контроля над доступом в файловой системе ext3 или контроль над доступом для объектов межпроцессного взаимодействия. А документация некоторых модулей PAM, использованная при экспертизе, не удовлетворяла требованиям Common Criteria к архитектуре высокого уровня. Заказчик экспертизы, IBM, принял решение о создании для SUSE Linux Enterprise Server 8 нового документа с описанием архитектуры высокого уровня, в котором особое внимание должно уделяться функциям защиты, определенным в описании защиты.

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

Функции защиты необходимо тщательно протестировать, причем тесты должны охватывать все функции и большинство их параметров и деталей. Для выполнения этого требования был значительно расширен тестовый пакет Linux Test Project (LTP): в него вошли тесты, связанные с функциями защиты.

Кроме того, Common Criteria требует анализа уязвимых мест, причем для сертификации EAL2 необходим лишь анализ высокого уровня. IBM разработала такую методику анализа, которая позволяет не только определить обнаруженные и ликвидированные за последние несколько лет уязвимости, но и выявить оставшиеся дефекты защиты.

Уроки

Для уровня EAL2 экспертиза свободно распространяемых продуктов аналогична экспертизе коммерческих решений. Процессы разработки тех и других на данном уровне различаются незначительно, но в соответствии с требованиями Common Criteria EAL2 в качестве объекта экспертизы была выбрана конкретная версия операционной системы. Анализировались разработка, управление конфигурацией, процедуры устранения дефектов разработчиком данной версии (SUSE). Накопленный при первой экспертизе опыт позволил убедиться, что свободно распространяемое программное обеспечение, управляемое и поддерживаемое авторитетной компанией, может удовлетворять требованиям к процессу разработки для сертификата более высокого уровня.

Выяснилось, что экспертизу даже такого сложного программного обеспечения, как Linux, можно провести очень быстро. На все ушло четыре месяца — с начала экспертизы до принятия организацией, выполняющей сертификацию по Common Criteria, необходимых технических отчетов. Конечно, на данном этапе требовалось получить лишь EAL2, сертификат довольно низкого уровня. Помогло и то, что в этом процессе участвовали специалисты, имеющие многолетний опыт сертификации Unix-подобных операционных систем.

Почему только сейчас

Экспертиза защиты операционных систем традиционна. Фактически Linux была единственной серверной операционной системой с постоянно растущим числом пользователей, которая не прошла такую экспертизу. Дело в том, что сама процедура обходится недешево, а сообщество Open Source и авторы дистрибутивов Linux не могли предоставить необходимые средства. Кроме того, для экспертизы было необходимо адаптировать функции защиты ОС к требованиям, предъявляемым к защите информационных систем коммерческими фирмами и госучреждениями. Сообщество свободно распространяемых решений не считало адаптацию предметом первой необходимости. Как правило, разработчики более заинтересованы в реализации функций, позволяющих решать технологические задачи, нежели тех, которые обеспечивают выполнение стандартных бизнес-требований.

Основные трудности

Главная трудность при экспертизе Linux была связана с имеющейся документацией. Это может показаться парадоксальным, но отсутствовала документация на архитектуру, необходимая для быстрого эффективного анализа защиты. Linux Documentation Project (www.tldp.org) содержит документацию по Linux, но эти документы, в основном, представляют собой руководства к действию, а не описания архитектуры.

Конечно, существует ряд полезных документов по ядру [4, 5]. Но, хотя эти материалы достаточно детальны и актуальны, они посвящены преимущественно не защите и в них отсутствуют определенные детали реализации. Более того, практически нет документов, которые описывают функции, не относящиеся к ядру (такие как PAM), или реализацию функций защиты, выполняющихся с привилегиями root. Вдобавок обнаружилась нехватка некоторых руководств, описывающих системные вызовы и важные конфигурационные файлы.

В Linux процессы разработки кода и документации на архитектуру друг с другом жестко не связаны. Зачастую специалисты, готовящие документацию на архитектуру, не входят в состав группы разработки. Те, кто модернизируют программное обеспечение, и те, кто обновляют документацию на архитектуру, не обязательно работают синхронно. Ни для одного вида документации на архитектуру, кроме руководств, не существует правил или регламентов, определяющих их структуру и создание. Как следствие, документация на архитектуру значительно различается по уровню детализации. В некоторых случаях информация, предоставленная разными источниками, дублируется, а в других функции вообще остаются неописанными.

Чтобы решить проблему с документацией, необходимой для экспертизы Linux, IBM разработала недостающие руководства и подготовила новый документ, касающийся защиты архитектуры высокого уровня. Этот подход позволит создавать документацию на архитектуру, отвечающую более серьезным требованиям, чем выдвигаемые при EAL2, и добиться более высоких уровней сертификации.

Поскольку существует проект Linux Test Project (ltp.sourceforge.net), содержащий пакет тестов для Linux, ситуация с тестированием оказалась несколько лучше ситуации с документацией. Фактически, Linux попала в те же условия, в которых оказывается при первой экспертизе любая коммерческая операционная система.

Важный положительный момент в случае свободно распространяемых программ, особенно на нижних уровнях экспертизы по критерию Common Criteria (вплоть до EAL4), — наличие исходных текстов. Только для EAL5 в Common Criteria содержится требование, чтобы разработчики предоставляли сертификационной организации полную версию всех исходных текстов. На уровне EAL4 должно быть представлено лишь подмножество исходных текстов, а на уровнях EAL1-EAL3 вообще не нужно передавать каких-либо исходных текстов.

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

В частности, эксперты подтвердили отсутствие руководств более чем для полусотни системных вызовов ядра 2.4.19. IBM подготовила недостающие руководства и выпустила их для сообщества свободно распространяемых решений. Кроме того, только в одной оболочке PAM эксперты нашли шесть критических к защите ошибок реализации. SUSE устранила эти дефекты и включила исправления в модернизацию PAM, вошедшую в состав оцениваемой конфигурации. Среди этих ошибок можно назвать следующие:

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

Основные выводы по результатам проекта таковы. Экспертиза по Common Criteria свободно распространяемых продуктов возможна, причем даже по отношению к столь сложному программному обеспечению, каким является полная версия Linux. Кроме того, экспертиза свободно распространяемых продуктов может проводиться довольно быстро. Наконец, теперь можно лучше представить, как добиться выполнения требований сертификации по Common Criteria более высоких уровней.

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

Шаги в этом направлении уже делаются. Linux, как и ее коммерческие конкуренты, успешно прошла экспертизу на соответствие требованиям CAPP. Уровень увеличен до EAL3 в соответствии с намерением обеспечить более строгую защиту Linux. Функциональность, включенная в экспертизу EAL3, выходит за рамки того, что требуется в CAPP. В том числе в Linux добавлена новая подсистема аудита событий, связанных с защитой.

Основные различия между EAL2 и EAL3 связаны с дополнительными требованиями к управлению конфигурацией и защите разработчика, с более детальным описанием архитектуры высокого уровня и с более строгим тестированием. Процедуры SUSE касаются требований управления конфигурацией и защиты разработчика. IBM добавила подробности в документ, описывающий архитектуру высокого уровня. Она также подготовила описания контрольных примеров и демонстраций, использующих инструментарий gcov для определения того, какие внутренние интерфейсы ядра вызываются при конкретных тестах. Документ для такой экспертизы можно найти на Web-сайте IBM. План тестирования и контрольные примеры для экспертизы опубликованы на Web-сайте Linux Test Project (ltp.sourceforge.net/ EAL3.html).

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

В настоящее времы atsec проводит экспертизу Linux на соответствие EAL4. Этот процесс включает в себя разработку архитектуры низкого уровня для ядра Linux (экспертиза будет выполняться для версии ядра 2.6) и требует более сложного анализа уязвимых мест. Опыт, полученный при экспертизе EAL2 и EAL3, дал уверенность в том, что соответствия EAL4 можно добиться к концу 2005 года. Поскольку экспертиза других операционных систем на соответствие этому уровню «за один шаг» заняла более трех лет, пошаговый подход кажется достаточно эффективным. Если добиться соответствия уровню EAL2 удалось за четыре месяца, EAL3 — еще за полгода, а для уровня EAL4 потребуется, видимо, год, то общее время сертификации Linux на соответствие уровню EAL4 составит меньше двух лет.

Литература
  1. ISO/IEC Standard 15408, Evaluation Criteria for IT Security, parts 1 to 3, Int?l Organization for Standards, 1999.
  2. C. Cowen. Software Security for Open-Source Systems. IEEE Security & Privacy, vol. 1, n. 1, January/February 2003.
  3. Controlled Access Protection Profile (CAPP), version 1.d, Nat?l Inst. of Standards and Technology, validated protection profile, 1999; niap.nist.gov/cc-scheme/pp/PP_CAPP_V1.d.html.
  4. T. Aivazian. Linux Kernal 2.4 Internals/ Linux Documentation Project, 2002; www.tldp.org/LDP/lki.
  5. D.P. Bovet, M. Cesati. Understanding the Linux Kernel, O?Reilly & Assoc., 2003.

Док Шанкар (dshankar@us.ibm.com) — специалист по информационной безопасности корпорации IBM.

Хельмут Курт (helmut@atsec.com) — один из основателей, директор по науке и глава подразделения Common Criteria агентства atsec.

Ресурсы процесса сертификации

Для того чтобы улучшить защищенность Linux, большая часть документов, разработанных в процессе эволюции этой операционной системы, была передана в хранилище свободно распространяемых программ корпорации IBM. Данная документация включает в себя описание механизмов защиты, руководства, описание архитектуры верхнего уровня, рекомендации и контрольные примеры.

Разработчики других версий ОС Linux могут использовать этот материал, адаптировав его к своим системам. В результате они сумеют провести экспертизу на соответствие Common Criteria, не тратя много времени и денег на подготовку таких документов.

Пока еще не принято решение о том, что делать с анализом уязвимых мест. Если опубликовать результаты такого анализа, ими могут воспользоваться хакеры, поскольку далеко не все изъяны удается эффективно устранить. С другой стороны, анализ уязвимостей может дать дополнительные сведения тем, кто отвечает за настройку и управление информационной системой на базе Linux. Как практически всегда бывает в случае свободно распространяемого программного обеспечения, публикация результатов анализа уязвимых мест имеет свои «за» и «против». Для достаточно высокоуровневого анализа это не столь критично, но данный вопрос будет становиться все острее по мере повышения уровня экспертиз, которые требуют более детального, «глубинного» анализа уязвимых мест.

K.S. (DOC) Shankar, Helmut Kurth, Certifying Open Source — The Linux Experience, Security & Privacy, November/December 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.