Стоит ли защищать от взлома двери дома, если его стены сделаны из фанеры? Безопасность такой конструкции в большей степени зависит от надежности стен — базовых элементов программного комплекса, а не от дверей — средств идентификации и управления доступом. Даже если к приложению пристроить мощную систему авторизации, шифрование в канале связи, активный аудит вместе с межсетевым экраном и оставить «фанерным» базовую функциональность, то хорошего результата не добиться.
Согласно статистике, больше половины атак используют ошибки в конкретных приложениях, а не архитектурные особенности сетевых протоколов или операционных систем. Поэтому, прежде чем заниматься усилением ворот — установкой дополнительных средств защиты приложений, лучше хорошо проверить набор их базовых возможностей и их влияние на общую безопасность системы. По такому пути сейчас идут разработчики операционных систем Windows и Linux.
Акцент на безопасность
Прежде всего, следует отметить разницу в подходах к укреплению защищенности и надежности для закрытых продуктов и программ с открытыми исходными текстами. Если исходные тексты программ доступны только ограниченному кругу лиц, то все остальные не смогут самостоятельно проверить, качественно ли исправлена ошибка или же предпринят лишь косметический ремонт. Убедиться в надежности коммерческих продуктов можно, только став их пользователем и внедрив соответствующие решения.
В то же время разработчики программ с открытыми кодами изначально вынуждены считаться с тем, что их продукты будут подвергнуты тщательному и непредвзятому анализу неограниченного круга специалистов. Поэтому вопрос об улучшении надежности и безопасности кода стоит достаточно остро. Кроме того, первоначальный продукт часто обзаводится вариациями с разной степенью функциональности и надежности, а пользователь (а точнее, редактор дистрибутива) уже может подобрать ту реализацию программы, которая полнее соответствует конкретным потребностям. В крайнем случае, пользователь (или дистрибьютор) может сам подправить наиболее интересные для него приложения или связаться напрямую с автором, потребовав исправления найденных ошибок. Коротко говоря, у пользователя программ с открытым кодом больше возможностей построить надежную информационную систему.
Для пользователей ОС Linux существенным является выбор поставщика дистрибутива, отличающегося стратегией подбора общедоступных программ, правилами сборки программ в пакеты и работы по устранению ошибок. Скажем, разработчики Red Hat и Debian в основном занимаются развитием функциональности программ, а различные варианты Mandrake сфокусированы на удобстве использования системы. Конечно, нельзя сказать, что, например, разработчики Red Hat совсем не занимаются безопасностью, однако предпочтение эти составители дистрибутивов отдают более функциональным программным продуктам. Есть разработчики, которые занимаются собиранием именно надежных дистрибутивов, например, дистрибутив Openwall Linux, Trustix Security Linux, ALT Linux или ASPLinux (он частично использует защищенные решения, но его основная стратегическая линия состоит в достижении совместимости с Red Hat).
Организационная защита
Основное отличие надежных дистрибутивов в наличии определенной стратегии подбора безопасных вариантов программ. Так, в дистрибутиве ALT Linux Master не пользуются стандартными утилитами su или login, предпочитая им более защищенные варианты. Общая же стратегия такова: если есть несколько реализаций утилиты или программы, то в дистрибутив попадает тот, который построен с большими требованиями к безопасности, даже если он обладает меньшей функциональностью. В результате клиент получает более защищенное решение, если он готов обойтись минимумом возможностей. Если же ему не достаточно предложенного набора функций, то пользователь может самостоятельно установить более сложный вариант дистрибутива, но тогда он сам должен позаботиться о сохранении уровня защищенности.
Кроме выбора более защищенных вариантов программ, разработчики надежных дистрибутивов проводят аудит кода выпускаемых программных продуктов; впрочем, из-за большого объема кода проверяются только привилегированные и сетевые программы. Для небольших утилит это можно сделать путем изучения исходных текстов. Если же приложение слишком велико, то на помощь могут прийти специальные анализаторы исходных текстов, которые автоматически находят опасные места. После анализа исходного кода можно с помощью встроенных датчиков проводить динамический анализ уже откомпилированных программ, однако пока у разработчиков ОС Linux нет общепринятой методики динамического анализа: все поведенческие тесты остаются на совести бета-тестировщиков.
Важным механизмом тестирования и устранения неисправностей является система контроля ошибок — BTS (Bug Tracking System). Внести ошибку в BTS или снять ее может любой пользователь, участвующий в тестировании. Для каждой ошибки определяется ее уровень, который может повлиять на выпуск дистрибутива или заставить перевести пакет в разряд менее надежных. В политике выпуска надежных дистрибутивов, как правило, присутствует такое требование: пока не решены проблемы определенного уровня, дистрибутив не будет выпущен. Менеджеры проекта могут изменить уровень ошибки — но только если с этим согласится тестировщик. Данная процедура позволяет пользователям участвовать в процессе разработки программного обеспечения с открытым кодом и напрямую, без посредников взаимодействовать с авторами программ.
Наиболее частые ошибки
У тестировщиков есть наборы стандартных ошибок, которые совершают начинающие кодировщики. Примером одной из неприятных ошибок может служить неправильная работа с временными файлами или другими временными объектами операционной системы. Если они создаются в фиксированном месте и с предсказуемыми именами, то у злоумышленника возникает возможность воздействовать на такой объект, например, для атаки на отказ в обслуживании. Часто подобные ошибки возникают в том случае, когда разработчик программы хочет добиться ее переносимости и использует универсальные механизмы взаимодействия процессов, которые не всегда достаточно хорошо защищены.
Еще одной частой ошибкой является временной разрыв между проверкой прав доступа к объекту и его реальным использованием: авторы программ обычно исходят из предположения, что атрибуты файла или другого объекта остались неизменными. Это может повлечь за собой получение неправильных данных, если состояние объекта и хранимой в нем информации изменились. Вероятность такого события не очень велика, однако оно, тем не менее, возможно. Для надежных систем подобная беспечность неприемлема. Ошибки рассинхронизации часто возникают в том случае, когда авторы не рассчитывают использовать свои программные продукты в многопоточной или многопроцессорной системе.
Есть более простые и достаточно известные ошибки, такие, например, как неправильная обработка исключительных ситуаций и кодов возврата. Собственно, большинство проблем возникает потому, что автор просто забыл где-то поставить необходимую проверку. Особенно сложно учесть все сочетания в сетевых программах и библиотеках, поскольку возможности протоколов стека TCP/IP достаточно обширны, в них есть много тонкостей и сложных сочетаний атрибутов пакетов, которые автор программы не всегда ожидает.
Технические приемы
Наиболее удобным способом является создание замкнутых сред исполнения с помощью команды chroot: даже если программа будет взломана или даст сбой, то она не сможет повредить другие компоненты. Такой способ защиты не позволяет нападающим использовать ошибки в одних программах для атаки на другие. В изолированные среды в основном помещают сетевые программы — как серверы, так и клиенты. Скажем, в дистрибутиве ALT Linux Master в замкнутые среды вынесены служба DNS и команда traceroute.
Логическим продолжением этой работы является разделение приложений на несколько различных потоков. В частности, если приложение выполняет большой ряд функций, а для одной из них требуются более высокие привилегии (например, для доступа к аппаратуре), то логично их выделить в отдельное приложение: контроль за ним, как правило, установить проще. Например, так устроен сервер Apache, который запускается с правами суперпользователя, чтобы иметь возможность обработки поступающих запросов на авторизацию, однако сам он не взаимодействует с сетевыми протоколами. Для этого порождается несколько потомков, которые обрабатывают сетевые запросы, но функционируют уже с правами обычных программ. Аналогичные действия по разделению больших приложений предпринимаются и для других сетевых служб.
Собственно, разделение приложений на несколько независимых частей помогает уменьшить количество программ, требующих установки флагов SUID и SGID, которые используются для разрешения проблем с полномочиями. Однако это вызывает определенные проблемы с безопасностью, если приложения, которым для работы требуется смена полномочий, выполняют слишком много функций и при этом имеют погрешности реализации. Тогда у нападающего может появиться возможность исполнить свой код с более высокими полномочиями. Уменьшить вероятность использования этих ошибок можно с помощью разделения приложений на несколько потоков; в один из них выделяются функции, требующие повышенных полномочий (для них-то и устанавливают флаг SGID или SUID), а все остальные функции выполняются под минимальными полномочиями. Однако понятно, что подобная перестройка программного обеспечения требует определенной культуры программирования.
Другие приемы
Кроме общесистемных подходов есть еще и технические приемы усиления наиболее важных элементов программы. В частности, это касается проверки полномочий и системы обновлений. Например, традиционно в ОС UNIX пароли для всех пользователей хранятся в одном файле, поэтому операционная система не может точно контролировать доступ к отдельным записям, что может быть использовано для изменения учетной информации. В защищенных вариантах Linux можно использовать раздельное хранение учетной информации. Так, например, построена система TCB, в которой учетная информация хранится отдельно для каждого пользователя в его каталоге, права на который принадлежат этому же пользователю. В результате, программа проверки полномочий может вначале уменьшить уровень своих полномочий, а уже потом проверять пароль. В этом случае, даже если программа проверки полномочий будет взломана, она не может получить доступа к учетной информации других пользователей — и уж тем более будет не в состоянии изменить ее.
Для усложнения процесса подбора идентификационной информации (пары «имя — пароль») важно обеспечить одинаковое время ответа программы проверки для разных путей ее исполнения. Если эту работу не проделать, то у нападающего появляется возможность подобрать с помощью статистических методов секрет, выясняя вначале существующие в системе имена, а затем уже для них подбирать пароли. По аналогии с этим, можно определить наличие псевдопользователей (таких, как lp или mail), чтобы в дальнейшем целенаправленно атаковать связанные с ними системы. Для предотвращения статистических методов атаки достаточно уравнять время прохождения запроса по всем веткам программы проверки полномочий. Такая работа, в частности, была проделана сотрудниками компании ALT Linux.
Важным компонентом защиты является и система обновлений программного обеспечения, которая должна сохранять наиболее общие настройки системы (например, права доступа к не всегда нужным, но потенциально опасным компонентам). Например, в защищенном дистрибутиве Openwall Linux (Owl) используется система сценариев owl-control, интегрированная в систему обновлений на основе RPM. Она же используется в дистрибутиве ALT Linux Master 2.2 для общих настроек доступа к различным аппаратным или привилегированным подсистемам. В частности, в Master 2.2 механизм owl-control используется для уменьшения привилегий некоторых программ после их установки. В частности, это можно сделать с программой записи компакт-дисков, утилитой управления коммутируемыми соединениями kppp и программой смены полномочий su. Причем, при обновлении каждой из этих программ настройки сохраняются, что позволяет поставлять пакеты программ с минимальными полномочиями, увеличивая их затем по мере необходимости. На эту систему контроля в Master 2.2 переведены все программы, которым необходима установка флагов SUID/SGID.
Дистрибутивы
Из надежных дистрибутивов в России, пожалуй, наиболее известен ALT Linux, а на Западе в эту когорту входят Owl, Trusted Debian и Trustix Security Linux. Однако мало сделать надежным конкретный набор программ — нужно еще соответствующим образом выстроить и сам процесс разработки дистрибутива. Минимальным требованием для этого является наличие системы обновлений желательно с сохранением общих настроек, например, с помощью owl-control. Естественно, у такого дистрибутива должна быть система контроля ошибок и аудита кода. Хотя код дистрибутива проверить и вычистить полностью не удалось пока никому, тем не менее, должна быть стратегия проведения аудита, которая определяла бы уровни проверки для разных частей дистрибутива.
В качестве примера рассмотрим реализацию описанных принципов в продуктах ALT Linux. Основу разработки дистрибутивов этой компании составляет репозиторий Sisyphus, с которым интегрирована система обновлений и контроля ошибок apt-get. Сам репозиторий разделен на несколько частей; для каждой из них используется своя политика обеспечения безопасности.
Одной из наиболее важных частей Sisyphus является набор ядерных пакетов Kernel. В этой части репозитория есть ядра с интегрированными в них защитными механизмами, такими как RSBAC или LIDS, а основной идеей безопасности является предоставление пользователям ядер с необходимым им набором защитных механизмов. Следующей частью Sisyphus является Base, куда собраны все базовые утилиты: TCB, owl-control, msulogin и другие. Для них выполняется полная проверка на безопасность и аудит кода, а их сборкой занимаются наиболее опытные специалисты. Перед публикацией эти пакеты проходят максимальное число проверок, к тому же ошибки в этих компонентах исправляются максимально быстро. Для этой части репозитория в ALT Linux были разработаны специальные требования по безопасной сборке пакетов.
Другая часть репозитория Castle проходит такие же проверки и в основном состоит из серверных программ, а от Base отличается только тем, что ее пакеты входят не во все продукты ALT Linux. Следующую часть составляют пользовательские программы, объединенные именем Junior. Требования по безопасности к ним достаточно высокие, хотя и ниже, чем для Castle. Все вместе перечисленные части являются компонентами Master: они входят в различные продукты ALT Linux и проходят обязательное тестирование на работоспособность и функциональность. Все новые и еще не проверенные пакеты попадают в раздел Contrib. Они не попадают в дистрибутивы — их устанавливают себе только самые опытные пользователи и тестировщики. Любой пакет, прежде чем войти в набор Master, должен пройти проверку в Contrib.
На основе описанной технологии разработки надежных дистрибутивов ALT Linux (на компонентах Master) построен сертифицированный дистрибутив «Утес-К». Он получил сертификат Гостехкомиссии на пятый класс защиты, допускающий работу с конфиденциальной информацией (литера «К» в названии расшифровывается как «конфиденциальный»). Впрочем, по этому классу может быть сертифицирован практически любой дистрибутив ОС Unix с минимальными дополнениями, такими как протоколирование определенных действий: открытие файла, запуск программы и другие. Основные отличия «Утес-К» от стандартного дистрибутива Master заключаются в наборе документации, соответствующей российскому ГОСТ.
