Содержание статьи
Ни для кого не секрет, что по-настоящему защищенных операционных систем не существует. Какие бы меры по повышению безопасности не предпринимали разработчики ОС, всегда остается вероятность того, что в их коде будет найдена ошибка, которая позволит обойти механизмы защиты. Однако прогресс не останавливается, и в противовес более изощренным атакам появляются более совершенные методы защиты. Qubes OS – пример того, как могут выглядеть эти методы в современном мире.
Зачем изобретать велосипед?
Чтобы понять, почему появилась на свет Qubes OS, и что она может дать в плане безопасности, мы должны углубиться в историю вопроса и выяснить, чем же плохи современные операционные системы.
Существует три наиболее эффективных метода обеспечения безопасности на уровне ОС:
- Формальное доказательство правильности и безопасности кода;
- Быстрое и своевременное решение выявленных проблем безопасности;
- Изоляция исполняемого кода (на уровне процессов и ядра).
Первый метод подразумевает полную проверку всего кода операционной системы (включая ядро и пользовательское ПО) и математическое доказательство того, что результат исполнения программы при любых условиях будет полностью соответствовать ожидаемому, а во время ее исполнения не произойдет непредвиденных ситуаций. Это – "святой грааль" для современных исследователей операционных систем (а также спецслужб всего мира). Однако, если брать в расчет неимоверную сложность сегодняшних ОС и количество оборудования, на котором они могут функционировать (необходимо доказать правильность работы ПО на любой аппаратной конфигурации), можно сказать, что на деле формальное доказательство безопасности всего кода ОС невозможно. За все время это удалось сделать лишь в отношении весьма скромных по размеру микроядер исследовательских ОС.
Некоторые разработчики предпочитают более простую проверку, полагаясь на свой опыт и не очень сложные инструменты (Flawfinder, RATS, Skavenger, lint и т.д.). Например, разработчики OpenBSD добились высокой безопасности ядра своей ОС во многом благодаря тому, что подвергают сомнению и тщательной проверке любой патч, предлагаемый к включению в ОС. Разработчики Coverity используют в своей системе (Coverity Prevent) довольно простые, но не слишком эффективные методы определения ошибок в коде. Третьи используют второй метод обеспечения безопасности и вместо тщательной проверки кода (которая требует внушительных затрат времени и средств) предпочитают своевременно и быстро выпускать обновления, решающие найденные проблемы в стабильности и безопасности. Сегодня эта практика распространена повсеместно и применяется всеми, начиная Microsoft и заканчивая разработчиками BSD-систем. Однако проблема метода в его запоздании. Зачастую первыми о баге узнают не разработчики ОС, а лица, приближенные к импер… человеку, нашедшему уязвимость. Поэтому еще до выхода багфикса поломанными оказываются сотни и тысячи машин.
Чтобы уменьшить ущерб от взлома, применяется изоляция кода. Современные процессоры предлагают механизм аппаратной защиты памяти, позволяя ядру и процессам пользователя работать в обособленных участках памяти и оберегая их друг от друга. Если взломанным оказывается один из пользовательских процессов, ядро остается в сохранности, а благодаря механизму прав доступа взломщик не получает контроль над всей ОС (если только взломанный сервис не работал с правами root). Это достаточно эффективный метод изоляции, но не стоит полностью полагаться только на него. Многие сервисы просто не могут быть запущены с правами рядовых пользователей, поэтому их взлом повлечет за собой компрометацию всей ОС, а ошибки в самом ядре ОС могут быть использованы для получения прав администратора, даже в том случае, если сервис работал от пользователя nobody и был изолирован с помощью SELinux или BSD Jail. А если проникновение произойдет через стандартное пользовательское ПО (веб-браузер, к примеру), то под угрозой окажутся все остальные пользовательские приложения и их данные (однако этого можно избежать, используя разные учетные записи для различных целей: покупки совершать под одним пользователем, переписку с друзьями вести под другим и т.п.).
Изоляция более низкого уровня
Получается, что наибольшую угрозу безопасности несет вовсе не ПО, работающее в пространстве пользователя, а ядро операционной системы. Сложное, огромное по размерам и количеству подсистем и драйверов монолитное ядро современной ОС – просто кладезь неоткрытых уязвимостей. Проникновение с использованием уязвимости в ядре дает взломщику абсолютную свободу, а простая ошибка – к падению всего и вся. Об этом всем нам долго и упорно повторял Эндрю Таненбаум, говоря о преимуществе микроядерных ОС с их разделением ядра на привилегированное микроядро и вынесением всех остальных подсистем (таких как драйвера, ФС, сетевой стек и даже менеджер памяти) в отдельные процессы. Не послушались, производительность оказалась дороже (микроядра несколько притормаживают), и сегодня все популярные ОС основаны на монолитном ядре.
Однако возможности современных процессоров позволяют перенести механизм изоляции еще глубже, который подразумевает использование виртуальных машин, работающих ниже ядра операционной системы. В этом случае можно использовать любые классические ОС и не беспокоиться о том, что ошибка в ядре будет использована для проникновения в виртуальную машину. Во-первых, ВМ может быть легко возвращена в предыдущее состояние, а во-вторых, никак не повлияет на другие виртуальные машины и их операционные системы. Этот подход уже давно используется провайдерами облачных вычислений. Но может ли тот же самый механизм быть применен для создания безопасной ОС для повседневного использования? Как оказалось – да.
Встречайте: Qubes OS
Qubes OS – это дистрибутив Linux (если в данном случае такое понятие вообще применимо), разрабатываемый под руководством небезызвестной Джоанны Рутковской, польского специалиста по безопасности. Основная идея Qubes OS в повсеместной изоляции на уровне виртуальных машин, при помощи которых осуществляется отделение пользовательских приложений от базовой ОС.
Кто она?
Джоанна Рутковска известна благодаря двум вещам. Во-первых, она является создателем нашумевшего и очень трудного в отлове руткита Blue Pill, который использует механизм аппаратной виртуализации для того, чтобы поместить всю ОС в виртуальную среду и вертеть ей, как вздумается. За это журнал eWeek поместил ее в пятерку хакеров, оставивших след в 2006 году (Five Hackers who Put a Mark on 2006). В 2009 году совместно с Rafal Wojtczuk она раскрыла способ атаки аппаратных механизмов защиты процессоров Intel TXT и Intel System Management Mode (SMM). Сегодня ей принадлежит компания Invisible Things Labs, которая занимается исследованиями в области безопасности операционных систем и систем виртуализации.
Сердце операционной системы – гипервизор Xen, используемый для запуска виртуальных машин, каждая из которых работает под управлением ядра Linux и набора стандартных служб и приложений уровня пользователя (их набор и количество может быть разным) и мультиплексирования ресурсов компа между ВМ. На рисунке "Архитектура Qubes OS" показана базовая архитектура ОС.
Каждое приложение (или набор приложений) запускается внутри обособленных виртуальных машин, четко отделенных друг от друга с помощью гипервизора. Для повышения безопасности весь сетевой код (включая сетевые драйвера, стек TCP/IP, DHCP-клиент и т.д.) работает в рамках отдельной виртуальной машины, так же как и код драйверов накопителей. Это возможно благодаря технологии виртуализации устройств Intel VT-d. Так называемая корневая виртуальная машина (Dom0 в терминологии Xen) используется для запуска всех остальных драйверов, системы X Window, графического менеджера окон и набора административных утилит для запуска приложений (виртуальных машин).
За счет Xen создателям Qubes OS удалось отодвинуть механизм изоляции исполняемого кода гораздо ниже, чем это сделано в классических операционных системах. В этой модели уязвимым местом становится не ядро операционной системы, а гипервизор, код которого в сотни раз меньше и гораздо проще (а значит, надежнее) кодовой базы ядра Linux. Механизмы обмена информацией между виртуальными машинами также намного более просты, чем их многочисленные аналоги для коммуникации между стандартными процессами в ядре ОС, а технология Intel VT-d, позволяющая вынести код драйверов в отдельные виртуальные машины, позволяет изолировать ненадежные, с точки зрения безопасности, драйвера.
Домены приложений
Все программы пользователя Qubes OS запускает внутри выделенных виртуальных машин, так называемых доменов приложений. Каждый из них работает под управлением полноценного дистрибутива Linux и потому кушает ресурсы весьма усердно. Чтобы свести к минимуму общую нагрузку на систему, Qubes OS использует несколько техник:
- Qubes OS использует аппаратную поддержку виртуализации современных процессоров (режим Xen HVM), а это значит, что производительность ОС, запущенной в рамках виртуальной машины, почти вплотную приближается к производительности ОС, работающей на "голом" железе.
- Qubes OS опирается на семантическое разграничение прав приложений, а это значит, что вместо того, чтобы помещать каждое приложение в отдельную виртуальную машину, ОС группирует их в рамках нескольких виртуальных машин по назначению и уровню доступа к конфиденциальной информации. Например, пользователь может создать домен Entertainment и использовать его для отдыха: запускать в нем аудио и видеоплееры, ходить по одноклассникам и YouTube. Домен под названием Shopping может быть использован для покупок в интернет-магазинах. Домен Banking – для интернет-банкинга и работы с пластиковыми картами. Смысл в том, что даже в том случае, если пользователь подцепит какую-нибудь гадость через одно из приложений домена Entertainment, его конфиденциальные данные, хранящиеся в доменах Shopping и Banking, останутся в сохранности. Это разумный компромисс, который позволяет существенно снизить потребление оперативной памяти (даже современный комп не потянул бы Qubes OS, если бы каждое ее приложение работало на отдельной ВМ).
- Для сохранения дискового пространства все домены приложений используют одну общую файловую систему. Домен хранилища, о котором пойдет речь в одноименном разделе статьи, хранит доступный только для чтения образ корневой файловой системы Linux. На его основе для каждого домена приложений создается устройство copy-on-write (это возможно благодаря механизму Device Mapper). Домен приложений монтирует файловые системы корневого образа и COW-устройства к корневому каталогу. Дополнительно для каждого домена приложений внутри домена хранилища создается образ для хранения приватных данных (каталоги /home, /usr/local, /var). Содержимое COW-устройства и образа приватных данных шифруется с помощью LUKS (The Linux Unified Key Setup), а ключ передается соответствующему домену приложений и административному домену. Благодаря такой схеме удается использовать один образ корневой ФС для всех доменов приложений и в тоже время обеспечить его сохранность от модификации. Шифрование позволяет обезопасить данные доменов приложений на тот случай, если взломщик проникнет в домен хранилища.
Административный домен
Административный домен (Xen Dom0) – наиболее привилегированный компонент Qubes OS. Он отвечает за управление доменами приложений, а его полномочия фактически равны полномочиям гипервизора. По этой причине административный домен сохранен максимально простым: пользователь не может запускать приложения в его рамках, а весь низкоуровневый код, участвующий в обмене данных с внешней стороной (сетевые драйвера, стек TCP/IP, DHCP-клиент, брандмауэр, драйвера накопителей и т.д.), вынесен в обособленные домены: сетевой домен и домен хранилища.
Внутри административного домена работают только два компонента ОС: демон XenStore, используемый для хранения информации о доменах, и GUI-подсистема, основанная на оконной системе X Window и окружении рабочего стола KDE (нет смысла выносить ее в отдельный домен, потому что получив доступ к GUI, взломщик автоматически получит доступ ко всем доменам приложений).
Графическая среда – одно из главных достижений разработчиков Qubes OS. Она не только предоставляет пользователям удобное и современное графическое окружение с применением 3D-эффектов, но и создает иллюзию того, что все приложения исполняются в рамках одной (виртуальной) машины. Приложения имеют собственные окна, и единственное, что отличает графический интерфейс Qubes OS от стандартного рабочего стола – это разноцветные рамки, обрамляющие окна. Так ОС отмечает виртуальные машины, в которых исполняется приложение. Без них пользователь мог бы сделать ошибку и ввести свои конфиденциальные данные не в том окне (приложение, которое предназначено для хождения по одноклассникам, а не для работы с кредитными картами, например).
Секрет GUI кроется в специальном демоне и собственном X-сервере (с "заглушкой" вместо видеодрайвера), работающим внутри каждого домена приложений. Когда происходит создание нового окна (или изменение содержимого существующего), демон получает его содержимое с помощью стандартной функции XGetImage системы X Window и, используя Xen Ring buffer protocol, отправляет его административному домену. Получив изображение, приложение AppViewer, работающее внутри административного домена, производит его отрисовку с помощью функции XRenderComposite.
Графический интерфейс Qubes OS не только реализует модель обособленных окон для приложений, но и позволяет производить копирование и вставку между окнами приложений, а в будущем планируется реализация поддержки аудио.
Сетевой домен
Сетевой код операционной системы представляет реальную опасность для ее пользователей. В то время как возможный баг в стеке протоколов TCP/IP, который отлаживался годами, очень маловероятен, опасная ошибка в драйвере для новой WiFi-карточки – не такая уж и редкость, как это может показаться на первый взгляд. Через эксплуатацию дыры в сетевом драйвере взломщик сможет получить полный контроль над ядром, а значит и над всей операционной системой.
По этой причине код всех сетевых драйверов в Qubes OS (Network Domain) вынесен в отдельную виртуальную машину, называемую сетевым доменом. В отличие от доменов приложений, он не разделяет общую корневую файловую систему с другими доменами, а вместо этого использует простое Linux-окружение, состоящее из брандмауэра, нескольких сетевых утилит и библиотек, нужных для их работы.
Есть только три вещи, которые сможет сделать взломщик, проникнув в сетевой домен: прослушивать трафик других доменов, попытаться произвести инъекцию собственных пакетов в этот трафик или же просто обрушить домен. В любом случае все это не приведет к катастрофическим последствиям, потому как трафик важных доменов, имеющих доступ к конфиденциальной информации, обычно шифруется, а трафик непривилегированного домена приложений, такого как Entertainment, защищать просто не имеет смысла. В случае же остановки сетевого домена его будет легко вернуть к последнему непротиворечивому состоянию (такая функциональность встроена в Qubes OS).
Каждый домен приложений получает доступ к сетевому оборудованию через виртуальный сетевой интерфейс, который Xen создает для каждой виртуальной машины. Внутри домена приложений он имеет стандартное имя eth0. На стороне сетевого домена этот виртуальный интерфейс отображается в интерфейс vifX.Y, где X – это идентификатор домена, а Y – номер интерфейса. Обычно при создании виртуальных окружений на основе Xen все эти интерфейсы vifX,Y соединяются с физическим интерфейсом (например, wlan0) в конфигурации bridge, так что каждая ВМ имеет доступ не только к физическому интерфейсу, но и ко всем другим ВМ. Для Qubes OS, ставящей во главу стола безопасность, такая схема неприемлема. Поэтому во время своего запуска и запуска доменов приложений сетевой домен не просто подключает виртуальные интерфейсы к физическому, но и настраивает брандмауэр так, чтобы домены приложений не смогли получить доступ друг к другу.
Домен хранилища
В современных ОС код, отвечающий за работу с накопителями, не менее комплексный, чем сетевая часть. Он включает в себя код драйверов устройств, реализацию протоколов ATA и SCSI, USB-стек, код демонов уровня пользователя. Каждый из этих компонентов может дать сбой или привести к взлому. Для запуска всего этого кода Qubes OS использует выделенную виртуальную машину, называемую доменом хранилища (Storage Domain).
В рамках домена хранилища работает весь код драйверов устройств хранения и все необходимые для их работы подсистемы ядра и демоны уровня пользователя. Также он отвечает за хранение образов корневой файловой системы Linux, образов для хранения приватных данных доменов приложений и файлов, необходимых для загрузки ОС (загрузочный раздел). Чтобы обезопасить эти данные от тех, кто смог проникнуть в домен хранилища, используются различные техники:
- Образы приватных данных доменов приложений шифруются. При этом ключ шифрования известен только соответствующему домену приложений и административному домену.
- Образ корневой файловой системы защищается от модификации с помощью цифровой подписи, ключ которой известен только административному домену. Если этот образ будет модифицирован, операционная система сообщит об этом пользователю.
- Защита загрузочных файлов ОС осуществляется с помощью доверенного механизма загрузки, основанного на технологии Intel TXT. Это значит, что, если загрузочные файлы будут модифицированы, операционная система просто не сможет загрузиться.
Единственное, что сможет сделать взломщик, завладев доменом хранилища, это вывести его из строя. Однако, как уже было сказано в предыдущем разделе, вышедший из строя домен Xen достаточно легко вернуть к предыдущему состоянию.
Процесс загрузки
Процесс загрузки Qubes OS можно условно разделить на семь этапов:
- Первый шаг включает в себя проверку подлинности файлов, необходимых для загрузки гипервизора и административного домена (не были ли они повреждены или модифицированы). Она осуществляется с помощью технологии Intel TXT (Trusted Execution Technology). Если проверка прошла успешно, то в следующих шагах ОС сможет получить доступ к ключам шифрования дисков из аппаратного модуля TPM (Trusted Platform Module).
- Далее происходит загрузка и запуск гипервизора, ядра административного домена и скрипта инициализации initramfs. Это происходит вне зависимости от результата проверки на первом этапе, однако если проверка дала ложный результат, ОС не сможет произвести загрузку остальных своих частей, так как не получит от TPM ключей шифрования.
- Скрипт initramfs запрашивает у пользователя пароль, который может быть введен вручную или хранится на карте памяти. Этот шаг необходим для того, чтобы только авторизованный пользователь смог получить доступ к системе. Если подлинность загрузочных файлов была подтверждена на первом шаге, и пользователь ввел правильный пароль, система может расшифровать файл keys.gpg, который содержит ключи, необходимые для следующих этапов загрузки.
- После расшифровки файла keys.gpg скрипт initramfs может приступить к созданию домена хранилища.
- Qubes OS создает новую виртуальную машину для домена хранилища и подключает к ней его корневую ФС, зашифрованную с использованием ключа, хранящегося в файле keys.gpg.
- Домен хранилища монтирует другой раздел, который используется для хранения образов корневых ФС и приватных данных доменов приложений. Теперь скрипт initramfs может смонтировать свою корневую файловую систему, запустить сетевой домен, систему X Window, окружение рабочего стола и таким образом завершить процесс загрузки.
- Система загружена и инициализирована. Теперь пользователь может запускать приложения.
Выводы
Qubes OS оказалась намного проще, чем этого можно было ожидать от по-настоящему безопасной операционной системы. По сути, она не приносит в мир ОС ничего кардинального нового, но показывает, что жесткая изоляция может применяться не только в отношении серверов, для сопровождения которых нужен грамотный администратор, и исследовательских ОС, таких как Singularity, но и в отношении ОС для рядовых пользователей. И это действительно большой шаг вперед.
