id: Гость   вход   регистрация
текущее время 00:28 27/12/2024
Автор темы: ntldr, тема открыта 11/06/2008 21:51 Печать
Категории: инфобезопасность, антивирусная защита
http://www.pgpru.com/Форум/ПрактическаяБезопасность/КонцепцияБезопаснойЗагрузки
создать
просмотр
ссылки

Концепция безопасной загрузки


Наверняка вы читали про Trusted Computing (TCPA, Palladium). Вкратце, это концептуальная система безопасной обработки информации, в которой может выполняться только довереный код. Для этого предлагается контролировать загрузку и работу ОС на всех уровнях, начиная с аппаратного контроля кода BIOS. Все это преподноситься как панацея от вредоносного ПО, но к сожалению панацеей это не является по причине того, что в архитектуре системы заложено постулируемое доверие к поставщикам "правильного" софта (а конкретно Microsoft), которые имеют право решать, какой софт вы можете использовать на своем компьютере, а какой нет.
Все это преимущественно будет использовано для создания всяких гнусных вещей, вроде DRM, и совершенно не защищает пользователя от вредоносных программ всем известной корпорации.


Я хочу предложить вам весьма похожую концепцию контроля за загружаемым кодом, в которой только владелец компьютера, и никто иной, имеет право решать, какому софту он доверяет.
Моя концепция состоит в верификации любого исполняемого кода по базе довереного софта, в идеале не должно быть никакой возможности выполнить недовереный код. Для этого необходима верификация всего загрузочного кода в процессе загрузки ос, и верификация кода драйверов и программ запускаемых после загрузки ос.
Основной частью системы верификации будет дополнительный модуль (optional rom) прошиваемый в BIOS и изменяющий процесс загрузки компьютера. Этот модуль содержит в себе открытый ключ, механизм загрузки каталогов довереного кода и механизм проверки кода по загруженым каталогам.
Каталог представляет из себя блок данных содержащий отсортированый список хэшей довереного кода и подписаный секретным ключем, открытая часть которого прошита в BIOS. Модуль безопасности BIOS ищет в конце диска загрузочную область, в которую прописан начальный загрузочный модуль и каталог довереного кода. Загрузочный код проверяется по каталогу, загружается в память, и ему передается управление. Начальный загрузчик грузит ядро и драйвера ранней стадии загрузки, и проверяет их код используя интерфейс предоставляемый BIOS, после чего в действие вступает драйвер проверяющий код всех запускаемых процессов и загружаемых драйверов.


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


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


 
На страницу: 1, 2 След.
Комментарии
— SATtva (15/06/2008 23:07)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Идея очень интересная, но возникают некоторые практические вопросы. В части ампутации ног у BIOS. А как быть с обновлением ядра? Вместе с ним заменять и материнку?
— ntldr (16/06/2008 09:32)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
А как быть с обновлением ядра? Вместе с ним заменять и материнку?

Вы просто пересоздаете каталог довереного кода и подписываете его своем ключем. Запускать что-либо на защищенной таким образом машине может только владелец ключа.

Вижу тема ни у кого не вызвала интереса. Очень хотелось бы поработать над этим вопросом с Linux/BSD гуру. Сам я не хочу и не могу потянуть еще один серьезный проект, поэтому нужны желающие сделать что-либо подобное. Я могу разработать архитектуру и написать патчи для bios и grub, а патчи к ядру и удобное управление всем этим должен делать кто-то другой.
Реализовывать такую защиту под проприетарные ОС считаю пустой тратой времени, так как их код никак не может быть довереным.
— Гость (16/06/2008 12:07)   <#>
Зачем BIOS? Доработай diskcryptor! Загрузка с CD-ROM.
— Гость (16/06/2008 13:24)   <#>
Вижу тема ни у кого не вызвала интереса.

Почему же, очень даже, но нет смысла писать "о, круто", или "пиши ещё", чтобы писать по существу нужно быть немного в теме архитектуры ОС и железа. Например, мне идея нравится, но прокомментировать ничго не могу. И вы уже правильно заметили, что нужен гуру открытых систем. Мб какой-нить google summer of code? Есть же открытые конкурсы на разработку проектов – где-нить бы пропихнуть...

Чисто технически мне не ясно какой код относить к исполняемому? Скрипты на шелле тоже? Вообще, весь список исполняемого кода – это довольно много... это почти весь
/usr. К тому же, основная проблема всё же – уязвимости софта... если проге сделать buffer overflow, которая в списке доверенного софта, ваш метод спасёт? И в целом не всегда можно точно сказать чему стоит доверять а чем нет – никто не проверяет абсолютно все исходники всего софта исполняемого на машине. Чем-то всё это напоминает hardware-based SeLINUX, только существенно менее функциональное, но зато в чём-то более надёжное :)

P. S.: а чё unknown молчит?
— SATtva (16/06/2008 13:36)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
если проге сделать buffer overflow, которая в списке доверенного софта, ваш метод спасёт?

Спасёт PaX. Вообще, если я не путаю, задача доверенной платформы (TPM, будь это самостоятельный чип или код в BIOS) — передать управление доверенному ядру. А уже это ядро будет отвечать за код, исполняемый в системе.

Чем-то всё это напоминает hardware-based SeLINUX

SELinux не защищает от подмены ядра. Это решает только TPM, в программной реализации, как здесь, или в аппаратной.
— ntldr (16/06/2008 13:56)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Зачем BIOS? Доработай diskcryptor!

DiskCryptor предназначен для windows, а концепция безопасной загрузки с мелкомягким проприетарным кодом принципиально несовместима. Если этот проект будет реализован, то только для открытых ОС.

Загрузка с CD-ROM.

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

Чисто технически мне не ясно какой код относить к исполняемому? Скрипты на шелле тоже?

В интерпретаторы скриптовых языков тоже очень желательно встроить проверку.

основная проблема всё же – уязвимости софта... если проге сделать buffer overflow, которая в списке доверенного софта, ваш метод спасёт?

Каковы бы не были уязвимости софта, злоумышленик лишен возможности установить в систему долговременный бекдор, так как не сможет ни добавить новый софт ни изменить существующий.
— Гость (16/06/2008 14:31)   <#>
В интерпретаторы скриптовых языков тоже очень желательно встроить проверку.

Есть перл. Он как бы скриптвый но на нём можно очень много чего понаписать, почти без ограничений. Что толку от того что злоумышленник не подменит интерпретатор, если он будет иметь возможность скармливать доверенному интерпретатору произвольный скрипт?

Каковы бы не были уязвимости софта, злоумышленик лишен возможности установить в систему долговременный бекдор, так как не сможет ни добавить новый софт ни изменить существующий.

А вот я не уверен... Ведь установить бэкдор можно и извращённым способом... К примеру, если из-за уязвимсти он получит возможность записи файлов, можно будет изменить опции конфигурации системы портов, что позволит ему втюхивать пользователю протрояненные порты. По своему же незнанию, пользователь внесёт их в доверенную базу... Ибо система валидации (проверки подписей сорсов) в системе портов не сработает как надо. Это пример превращения "кратковременного бэкдора" в "долговременный". И подобного можно придумать кучу.
— Гость (16/06/2008 14:36)   <#>
Имхо, после соответствующей добработки можно показать, что для "доверенности" потребуется доверять каждому файлу на машине, и, соответственно, каждому изменению каждого файла. Таким образом, пользователь должен был бы взять на себя функции самой ОС, но технически это не осуществимо :)
— Гость (16/06/2008 15:49)   <#>
Более того, при компиляции из сорсов/портов аозникают моменты когда исполняемый файл или его исходник или ещё что-то формируются динамически... Неужто обновлять базу тоже прийдётся динамически, доверяя какому-нить автоконфу (autoconf)? Я так понимаю, идея в конце концов сводится к тому, что перепрошитый биос лишь будет делегировать свои полномочия той или иной программе, в итоге в каталоге доверенного софта будет находиться лишь "первый слой программ", и каждая прога из этого слоя будет обладать полномочиями наделять ими другой софт, как-то с ней связанный (интепретатор эффективно наделяет ими исполнямый им скрипт, etc).

Эта схема порождает больше вопросов чем ответов... И после детальной обработки и анализа может либо вообще рассыпаться, либо станет одной из дополнительных полумер против заявленной угрозы.
— SATtva (16/06/2008 19:04)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Я бы не изобретал велосипед. Существует SELinux и другие системы мандатного контроля доступа, которые и предназначены для ограничения привилегий системных процессов[1]. Но есть область, находящаяся вне их досягаемости: контроль над загрузчиком и ядром. Если есть способ для решения этой проблемы, стоит сосредоточиться на нём (объять необъятное всё равно не получится).

Итак, доверенный код в BIOS контролирует процесс загрузки через доверенный загрузочный код и передачу управления доверенному ядру. Затем ядро принимает полномочия и использует доступный ему арсенал средств для контроля над исполняемым кодом. Если противник будет лишён возможности подменить ядро (или виртуализировать систему какой-нибудь "синей таблеткой"), подвергнуть риску внутренний периметр станет для него существенно сложнее.

[1] Попытки ограничить возможности исполняемых скриптов, встроив механизмы ограничения в интерпретатор, предпринимались неоднократно, но, за исключением Java, оставались безуспешными. И даже в Java VM периодически выявляются бреши, допускающие выход из песочницы.
— unknown (16/06/2008 23:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Есть небольшое количество материнок, которые поддерживают OpenBIOS или LinuxBIOS.
В таком биосе умельцам удавалось даже запустить урезанную версию иксов с оконным менеджером и графическим браузером :-)

Есть какой-то патч к ядру, который позволяет грузить только подписанные бинарники. Не знаю насколько после этого тормозит запуск всех программ.

В принципе можно было бы пропатчить ещё и менеджер пакетов, так чтобы после проверки подписи обновлений ОС, которую он делает сам по gpg-ключу дистрибутива, все бинарники из него сначала бы распаковывались во временную диру и подписывались бы (вот только чем это сделать в процессе работы системы?).
— SATtva (17/06/2008 11:59)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Есть какой-то патч к ядру, который позволяет грузить только подписанные бинарники. Не знаю насколько после этого тормозит запуск всех программ.

Ну, по существу это ведь только операции хэширования, и если это SHA-1 или SHA-256, то скорость не должна сильно пострадать. Исключение представляет только сервер, который при каждом коннекте вызывает CGI-скрипт через запуск интерпретатора, к примеру.
— unknown (20/06/2008 22:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А это дело уже кстати давно финансирует европейская коммисия. Скоро уже грант закончится:



Financing: European Commission – Framework Program 6 (EC – FP6)

Project reference Nr.: IST-027635
Start: 2005-11-01
End: 2009-04-30

Project website: http://www.opentc.net

Description:
The Open Trusted Computing (OpenTC) consortium is an R&D project focusing on the development of trusted and secure computing systems based on open source software. The project targets traditional computer platforms as well as embedded systems such as mobile phones. The goal of OpenTC is to reduce system-related threats, errors and malfunctions.



— SATtva (21/06/2008 17:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Всё-таки не совсем то. Я только пробежал по описанию, но это похоже на открытую реализацию программной составляющей TCP, опирающейся на обычные аппаратные модули TPM. В отличие от предложения ntldr, к его благу или беде, уж не знаю.
— Гость (03/05/2009 14:48)   <#>
Читайте к чему ЭТО может привести
Я был в шоке!
http://www.interface.ru/microsoft/news/n021211797.htm
http://www.againsttcpa.com/tcpa-faq-en.html
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3