Добавлен: 29.10.2018
Просмотров: 48149
Скачиваний: 190
666
Глава 9. Безопасность
И все же наиболее важные инциденты, связанные с безопасностью, относятся к изо-
щренным кибератакам. В данной книге особое внимание будет уделено атакам, имею-
щим отношение к операционным системам. Иными словами, мы не будем рассматри-
вать веб-атаки, или атаки на базы данных SQL. Вместо этого мы сконцентрируемся на
атаках, которые либо нацелены на операционные системы, либо играют важную роль
в обеспечении выполнения (или чаще всего в препятствии выполнению) политики
безопасности.
В общем, мы будем различать атаки, пассивно пытающиеся похитить информацию,
и атаки, активно пытающиеся нарушить поведение компьютерной программы. При-
мером пассивной атаки является враг, подключившийся к сетевому трафику и пытаю-
щийся взломать шифр (если таковой имеется) для получения данных. При активной
атаке злоумышленник может получить управление веб-браузером пользователя, за-
ставив его выполнить вредоносный код, например, для кражи реквизитов кредитной
карты. Точно так же мы будем различать криптографию, которая целиком посвящена
перетасовке сообщения или файла способом, затрудняющим восстановление исходных
данных без ключа, и укрепление (hardening) программ, добавляющее к программам
механизм защиты, затрудняющий взломщикам изменение их поведения. Операцион-
ная система использует криптографию во многих местах: для безопасной передачи
данных по сети, безопасного хранения файлов на диске, шифрования паролей в файле
с паролями и т. д. Также повсеместно используется и укрепление программ: для того
чтобы предотвратить внедрение взломщиками нового кода в работающую программу,
обеспечения того, что у каждого процесса имеются именно те привилегии, которые ему
нужны и которые для него предусмотрены, и не выше, и т. д.
9.2.1. Можно ли создать защищенные системы?
Сегодня невозможно открыть газету и не прочитать еще одну историю о взломщиках,
проникших в компьютерные системы, похитивших информацию или взявших под
контроль миллионы компьютеров. При таком положении дел можно задать два про-
стых и вполне логичных вопроса:
1. А нельзя ли создать защищенную компьютерную систему?
2. Если да, то почему она до сих пор не создана?
Ответ на первый вопрос будет таким: «Теоретически можно». В принципе, программа
может быть избавлена от ошибок, и мы даже можем убедиться в ее защищенности,
если только эта программа не слишком велика или сложна. К сожалению, современ-
ные компьютерные системы ужасно сложны, что перекликается с ответом на второй
вопрос. Ответ на вопрос, почему еще не созданы абсолютно защищенные системы,
сводится к двум основным причинам. Во-первых, сегодняшние системы не являются
защищенными, но пользователи не собираются от них отказываться. Если бы, к при-
меру, корпорация Microsoft объявила, что кроме системы Windows у нее есть новый
продукт, SecureOS, невосприимчивый к вирусам, но не выполняющий приложения
Windows, то вряд ли все частные пользователи и компании тут же отказались бы от
Windows и купили новую систему. У Microsoft есть защищенная операционная система
(Fandrich et al., 2006), но она не выводит ее на рынок. Вторая причина не столь очевид-
на. Единственный известный способ создать защищенную систему заключается в под-
держании ее простоты. Функциональные возможности являются врагом безопасности.
Бравые ребята из маркетингового отдела в большинстве технологических компаний
9.2. Безопасность операционных систем
667
полагают (справедливо или нет), что пользователям хочется все больше функциональ-
ных возможностей, еще более широких и более качественных. Они убеждены в том,
что разработчики системных структур их программных продуктов получат на это
соответствующие указания. Но все это означает повышение сложности системы, все
большее количество кода, большее число дефектов и ошибок в системе безопасности.
Приведем два весьма простых примера. В первых системах электронной почты со-
общения отправлялись в виде ASCII-текста. Они были простыми, и их можно было
сделать совершенно безопасными. Хотя в почтовых программах есть тупые баги, вряд
ли ASCII-сообщение может сломать компьютерную систему (позднее мы еще обсудим
несколько возможных атак). Затем появилась идея расширить возможности сообщений
и включить в них другие типы документов, например файлы редактора Word, которые
могут содержать макросы. Чтение такого документа означает запуск чужой программы
на вашем компьютере. Независимо от применяемых механизмов безопасности запуск
чужой программы на вашем компьютере намного опаснее, чем просмотр ASCII-текста.
Нужна ли была пользователям возможность изменять содержимое электронной по-
чты с пассивных документов на активные программы? Наверное, нет, но кому-то эти
перемены показались замечательной идеей, при этом о последствиях для безопасности
никто особо не думал.
Второй пример касается веб-страниц. Когда во Всемирной паутине использовались
пассивные HTML-страницы, ничто не предвещало существенных проблем с без-
опасностью. Теперь же, когда многие веб-страницы содержат программы (апплеты
и сценарии на JavaScript), которые пользователь должен запустить, чтобы просмотреть
содержимое, возникают все новые прорехи в системе безопасности. Стоит только
устранить одну из них, на ее месте появляется другая. Когда Всемирная паутина имела
полностью статичный характер, разве было такое, чтобы пользователи поднимали обе
руки, голосуя за динамическое наполнение? Что-то не припомнится, а вот ввод этого
наполнения привнес целый ворох проблем безопасности. Похоже, что вице-президент,
который должен был возразить, просто уснул за рулем.
И все же еще есть ряд организаций, полагающих, что хорошая система безопасности
важнее, чем модные навороты, и в первую очередь это касается военных. В следующих
разделах будет рассмотрен ряд соответствующих вопросов, которые можно свести
в одно предложение. Для создания защищенной системы нужно воспользоваться
моделью безопасности в ядре операционной системы, которая была бы достаточно
простой для понимания ее сути разработчиками и смогла бы сопротивляться любому
давлению, всячески уклоняясь от добавления новых функциональных возможностей.
9.2.2. Высоконадежная вычислительная база
В кругах специалистов по компьютерной безопасности часто ведутся разговоры
о надежных системах (trusted systems), а не о защищенных системах. Это системы,
имеющие официально установленные требования к безопасности и соблюдающие эти
требования. В основе каждой надежной системы находится минимальная база TCB
(Trusted Computing Base — высоконадежная вычислительная база), состоящая из аппа-
ратного и программного обеспечения, необходимого для принудительного выполнения
всех мер безопасности. Если высоконадежная вычислительная база работает в соот-
ветствии с техническими условиями, безопасность системы не может быть нарушена
ни при каких других неблагоприятных обстоятельствах.
668
Глава 9. Безопасность
Обычно TCB состоит в основном из аппаратного обеспечения (кроме устройств ввода-
вывода, не влияющих на безопасность), части ядра операционной системы и большей
части или всех пользовательских программ, обладающих полномочиями привиле-
гированного пользователя (например, программы с установленным битом SETUID
в корневом каталоге системы UNIX). К функциям операционной системы, которые
должны быть частью TCB, относятся следующие: создание процесса, переключение
процессов, управление отображением памяти, а также часть управления файлами
и вводом-выводом данных. В конструкции надежной системы TCB зачастую полно-
стью отделена от остальной операционной системы с целью сведения к минимуму ее
размера и проверки ее корректности.
Важную часть высоконадежной вычислительной базы составляет монитор обращений
(рис. 9.1). Он принимает все системные вызовы, имеющие отношение к безопасности,
например вызов для открытия файлов, и принимает решение, следует их обрабатывать
или нет. Таким образом, монитор обращений позволяет поместить все решения о без-
опасности в одном месте, не давая их обойти. Организация большинства операционных
систем отличается от данной схемы, в чем заключается одна из причин их ненадежности.
Рис. 9.1. Монитор обращений
Одной из целей некоторых современных исследований в сфере безопасности является
сокращение объема высоконадежной вычислительной базы с нескольких миллионов
строк кода до всего лишь десятков тысяч. На рис. 1.22 показана структура операцион-
ной системы MINIX 3, которая является POSIX-совместимой системой, но с совер-
шенно иной структурой, чем у Linux или у FreeBSD. В ядре MINIX 3 работает всего
лишь около 10 000 строк программного кода. Весь остальной код запускается в виде
набора процессов пользователя. Часть кода ядра, к примеру файловая система и дис-
петчер процессов, входит в высоконадежную вычислительную базу, поскольку этот
код запросто может подорвать безопасность системы. Но остальные части, к примеру
драйвер принтера и драйвер звуковой карты, не входят в высоконадежную вычисли-
тельную базу, и все их сбои не имеют никакого значения (даже если они произошли из-
за вируса), они ничем не могут подорвать безопасность системы. За счет уменьшения
высоконадежной вычислительной базы на два порядка системы, подобные MINIX 3,
могут потенциально предоставить более высокую степень безопасности, чем традици-
онные конструктивные решения.
9.3. Управление доступом к ресурсам
669
9.3. Управление доступом к ресурсам
Безопасности проще достичь, если есть четкая модель того, что должно быть защищено
и кому и что разрешено делать. В этой области проделан очень большой объем работы,
поэтому в данном кратком изложении мы можем сделать лишь поверхностный обзор.
Мы сконцентрируем внимание на ряде общих моделей и механизмов их применения.
9.3.1. Домены защиты
Компьютерная система содержит множество ресурсов или объектов, нуждающихся
в защите. Этими объектами могут быть оборудование (например, центральные про-
цессоры, страницы памяти, дисковые приводы или принтеры) или программное обе-
спечение (например, процессы, файлы, базы данных или семафоры).
У каждого объекта есть уникальное имя, по которому к нему можно обращаться,
и конечный набор операций, которые процессы могут выполнять в отношении этого
объекта. Файлу свойственны операции read и write, а семафору — операции up и down.
Совершенно очевидно, что нужен способ запрещения процессам доступа к тем объ-
ектам, к которым у них нет прав доступа. Более того, этот механизм должен также
предоставлять возможность при необходимости ограничивать процессы поднабором
разрешенных операций. Например, процессу A может быть дано право проводить чте-
ние данных из файла F, но не разрешено вести запись в этот файл.
Чтобы рассмотреть различные механизмы защиты, полезно ввести понятие домена.
Домен
(domain) представляет собой множество пар (объект, права доступа). Каждая
пара определяет объект и некоторое подмножество операций, которые могут быть
выполнены в отношении этого объекта. Права доступа (rights) означают в данном
контексте разрешение на выполнение той или иной операции. Зачастую домен соот-
носится с отдельным пользователем, сообщая о том, что может, а что не может сделать
этот пользователь, но он может также иметь и более общий характер, распространяясь
не только на отдельного пользователя. К примеру, сотрудники одной группы про-
граммистов, работающие над одним и тем же проектом, могут целиком принадлежать
к одному и тому же домену и иметь доступ к файлам проекта.
Распределение объектов по доменам зависит от особенностей того, кому и о чем нужно
знать. Тем не менее одним из фундаментальных понятий является принцип минималь-
ных полномочий
(Principle of Least Authority (POLA)), или принцип необходимого
знания. В общем, безопасность проще соблюсти, когда у каждого домена имеется ми-
нимум объектов и привилегий для работы с ними и нет ничего лишнего.
На рис. 9.2 показаны три домена с объектами в каждом из них и правами на чтение,
запись и выполнение (Read, Write, eXecute) применительно к каждому объекту. Заметь-
те, что объект Printer1 одновременно находится в двух доменах и обладает одинаковыми
правами в каждом из них. Объект File1 также присутствует в двух доменах, но имеет
разные права в каждом из них.
В любой момент времени каждый процесс работает в каком-нибудь домене защиты.
Иными словами, существует некая коллекция объектов, к которым он может иметь
доступ, и для каждого объекта у него имеется некий набор прав. Во время работы про-
цессы могут также переключаться с одного домена на другой. Правила переключения
между доменами сильно зависят от конкретной системы.
670
Глава 9. Безопасность
Рис. 9.2. Три домена защиты
Чтобы конкретизировать идею домена защиты, рассмотрим пример из системы UNIX
(который также относится к Linux, FreeBSD и им подобным клонам). В UNIX домен
процесса определяется его идентификаторами UID и GID. Когда пользователь входит
в систему, его оболочка получает UID и GID, которые содержатся в его записи в файле
паролей, и они наследуются всеми его дочерними процессами. Представляя любую
комбинацию (UID, GID), можно составить полный список всех объектов (файлов,
включая устройства ввода-вывода, которые представлены в виде специальных файлов
и т. д.), к которым процесс может обратиться с указанием возможного типа доступа
(чтение, запись, исполнение). Два процесса с одинаковой комбинацией (UID, GID)
будут иметь абсолютно одинаковый доступ к одинаковому набору объектов. Процес-
сы с различающимися значениями (UID, GID) будут иметь доступ к разным наборам
файлов, хотя, может быть, и со значительным перекрытием этих наборов.
Более того, каждый процесс в UNIX состоит из двух частей: пользовательской и си-
стемной (выполняемой в ядре). Когда процесс осуществляет системный вызов, он пере-
ключается из пользовательской части в системную. По сравнению с пользовательской
частью системная часть имеет доступ к другому набору объектов. Например, системная
часть процесса может иметь доступ ко всем страницам в физической памяти, ко всему
диску и ко всем другим защищенным ресурсам. Таким образом, системный вызов яв-
ляется причиной для переключения доменов защиты.
Когда процесс осуществляет системный вызов exec в отношении файла, у которого
установлен бит SETUID или бит SETGID, он получает новый действующий иденти-
фикатор UID или GID. С другой комбинацией (UID, GID) он имеет и другой набор
доступных файлов и операций. Запуск программы с установленным битом SETUID
или битом SETGID также вызывает переключение домена, так как при этом изменя-
ются права доступа. Важно знать, как именно система отслеживает принадлежность
объекта к тому или иному объекту. Концептуально можно представить себе большую
матрицу, в которой строками будут домены, а колонками — объекты. В каждой ячейке
перечисляются права, если таковые имеются, которыми располагает домен по отноше-
нию к объекту. Матрица для рис. 9.2 показана на рис. 9.3. Располагая этой матрицей
и номером текущего домена, операционная система может определить, разрешен ли из
конкретного домена определенный вид доступа к заданному объекту.
Само по себе переключение между доменами также может быть легко включено в ту же
табличную модель, если в качестве объекта представить сам домен, в отношении кото-
рого может быть разрешена операция входа — enter. На рис. 9.4 снова показана матрица
с рис. 9.3, но теперь на ней в качестве объектов фигурируют и сами три домена. Про-
цессы в домене 1 могут переключаться на домен 2, но обратно вернуться уже не могут.
Эта ситуация моделирует в UNIX выполнение программы с установленным битом
SETUID. Другие переключения доменов в данном примере не разрешены.