Концепция безопасной загрузки
Наверняка вы читали про Trusted Computing (TCPA, Palladium). Вкратце, это концептуальная система безопасной обработки информации, в которой может выполняться только довереный код. Для этого предлагается контролировать загрузку и работу ОС на всех уровнях, начиная с аппаратного контроля кода BIOS. Все это преподноситься как панацея от вредоносного ПО, но к сожалению панацеей это не является по причине того, что в архитектуре системы заложено постулируемое доверие к поставщикам "правильного" софта (а конкретно Microsoft), которые имеют право решать, какой софт вы можете использовать на своем компьютере, а какой нет.
Все это преимущественно будет использовано для создания всяких гнусных вещей, вроде DRM, и совершенно не защищает пользователя от вредоносных программ всем известной корпорации.
Я хочу предложить вам весьма похожую концепцию контроля за загружаемым кодом, в которой только владелец компьютера, и никто иной, имеет право решать, какому софту он доверяет.
Моя концепция состоит в верификации любого исполняемого кода по базе довереного софта, в идеале не должно быть никакой возможности выполнить недовереный код. Для этого необходима верификация всего загрузочного кода в процессе загрузки ос, и верификация кода драйверов и программ запускаемых после загрузки ос.
Основной частью системы верификации будет дополнительный модуль (optional rom) прошиваемый в BIOS и изменяющий процесс загрузки компьютера. Этот модуль содержит в себе открытый ключ, механизм загрузки каталогов довереного кода и механизм проверки кода по загруженым каталогам.
Каталог представляет из себя блок данных содержащий отсортированый список хэшей довереного кода и подписаный секретным ключем, открытая часть которого прошита в BIOS. Модуль безопасности BIOS ищет в конце диска загрузочную область, в которую прописан начальный загрузочный модуль и каталог довереного кода. Загрузочный код проверяется по каталогу, загружается в память, и ему передается управление. Начальный загрузчик грузит ядро и драйвера ранней стадии загрузки, и проверяет их код используя интерфейс предоставляемый BIOS, после чего в действие вступает драйвер проверяющий код всех запускаемых процессов и загружаемых драйверов.
При установке этой системы мы генерируем ключ, создаем каталог довереного кода и подписываем его своим ключем, после чего ключ внедряется в модуль безопасности который прошивается в BIOS. После этого отпиливаем от микросхемы BIOS ножку разрещающую запись, и заливаем чип эпоксидкой. Теперь вы обладаете полным контролем над вашим компьютером, и без вашего ведома на нем нельзя выполнить код.
Меня интересуют комментарии к концепции, советы по ее улучшению, и рекомендации по выбору используемых алгоритмов и из конкретных реализаций.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 371 документов: 19 редакций: 20
Вы просто пересоздаете каталог довереного кода и подписываете его своем ключем. Запускать что-либо на защищенной таким образом машине может только владелец ключа.
Вижу тема ни у кого не вызвала интереса. Очень хотелось бы поработать над этим вопросом с Linux/BSD гуру. Сам я не хочу и не могу потянуть еще один серьезный проект, поэтому нужны желающие сделать что-либо подобное. Я могу разработать архитектуру и написать патчи для bios и grub, а патчи к ядру и удобное управление всем этим должен делать кто-то другой.
Реализовывать такую защиту под проприетарные ОС считаю пустой тратой времени, так как их код никак не может быть довереным.
Почему же, очень даже, но нет смысла писать "о, круто", или "пиши ещё", чтобы писать по существу нужно быть немного в теме архитектуры ОС и железа. Например, мне идея нравится, но прокомментировать ничго не могу. И вы уже правильно заметили, что нужен гуру открытых систем. Мб какой-нить google summer of code? Есть же открытые конкурсы на разработку проектов – где-нить бы пропихнуть...
Чисто технически мне не ясно какой код относить к исполняемому? Скрипты на шелле тоже? Вообще, весь список исполняемого кода – это довольно много... это почти весь
/usr. К тому же, основная проблема всё же – уязвимости софта... если проге сделать buffer overflow, которая в списке доверенного софта, ваш метод спасёт? И в целом не всегда можно точно сказать чему стоит доверять а чем нет – никто не проверяет абсолютно все исходники всего софта исполняемого на машине. Чем-то всё это напоминает hardware-based SeLINUX, только существенно менее функциональное, но зато в чём-то более надёжное :)
P. S.: а чё unknown молчит?
комментариев: 11558 документов: 1036 редакций: 4118
Спасёт PaX. Вообще, если я не путаю, задача доверенной платформы (TPM, будь это самостоятельный чип или код в BIOS) — передать управление доверенному ядру. А уже это ядро будет отвечать за код, исполняемый в системе.
SELinux не защищает от подмены ядра. Это решает только TPM, в программной реализации, как здесь, или в аппаратной.
комментариев: 371 документов: 19 редакций: 20
DiskCryptor предназначен для windows, а концепция безопасной загрузки с мелкомягким проприетарным кодом принципиально несовместима. Если этот проект будет реализован, то только для открытых ОС.
Одна из целей проекта – защитить систему от атакующего имеющего к ней периодический физический доступ. Предполагается что незаметно подменить мамку такой атакующий не в состоянии, а внедрение бекдоров в ОС и прошивки карт расширения должно стать невозможно.
В интерпретаторы скриптовых языков тоже очень желательно встроить проверку.
Каковы бы не были уязвимости софта, злоумышленик лишен возможности установить в систему долговременный бекдор, так как не сможет ни добавить новый софт ни изменить существующий.
Есть перл. Он как бы скриптвый но на нём можно очень много чего понаписать, почти без ограничений. Что толку от того что злоумышленник не подменит интерпретатор, если он будет иметь возможность скармливать доверенному интерпретатору произвольный скрипт?
А вот я не уверен... Ведь установить бэкдор можно и извращённым способом... К примеру, если из-за уязвимсти он получит возможность записи файлов, можно будет изменить опции конфигурации системы портов, что позволит ему втюхивать пользователю протрояненные порты. По своему же незнанию, пользователь внесёт их в доверенную базу... Ибо система валидации (проверки подписей сорсов) в системе портов не сработает как надо. Это пример превращения "кратковременного бэкдора" в "долговременный". И подобного можно придумать кучу.
Эта схема порождает больше вопросов чем ответов... И после детальной обработки и анализа может либо вообще рассыпаться, либо станет одной из дополнительных полумер против заявленной угрозы.
комментариев: 11558 документов: 1036 редакций: 4118
Итак, доверенный код в BIOS контролирует процесс загрузки через доверенный загрузочный код и передачу управления доверенному ядру. Затем ядро принимает полномочия и использует доступный ему арсенал средств для контроля над исполняемым кодом. Если противник будет лишён возможности подменить ядро (или виртуализировать систему какой-нибудь "синей таблеткой"), подвергнуть риску внутренний периметр станет для него существенно сложнее.
[1] Попытки ограничить возможности исполняемых скриптов, встроив механизмы ограничения в интерпретатор, предпринимались неоднократно, но, за исключением Java, оставались безуспешными. И даже в Java VM периодически выявляются бреши, допускающие выход из песочницы.
комментариев: 9796 документов: 488 редакций: 5664
В таком биосе умельцам удавалось даже запустить урезанную версию иксов с оконным менеджером и графическим браузером :-)
Есть какой-то патч к ядру, который позволяет грузить только подписанные бинарники. Не знаю насколько после этого тормозит запуск всех программ.
В принципе можно было бы пропатчить ещё и менеджер пакетов, так чтобы после проверки подписи обновлений ОС, которую он делает сам по gpg-ключу дистрибутива, все бинарники из него сначала бы распаковывались во временную диру и подписывались бы (вот только чем это сделать в процессе работы системы?).
комментариев: 11558 документов: 1036 редакций: 4118
Ну, по существу это ведь только операции хэширования, и если это SHA-1 или SHA-256, то скорость не должна сильно пострадать. Исключение представляет только сервер, который при каждом коннекте вызывает CGI-скрипт через запуск интерпретатора, к примеру.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
Я был в шоке!
http://www.interface.ru/microsoft/news/n021211797.htm
http://www.againsttcpa.com/tcpa-faq-en.html