Подписанные исполняемые файлы под Linux

https://stackoverflow.com/questions/1732927

20-09-2019
|

Вопрос

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

Как подписать исполняемый код и запускать только проверенное программное обеспечение под Linux?

Я читал работу ван Дума et al., Разработка и внедрение подписанных исполняемых файлов для Linux, и IBM's ТСХ (Доверенный клиент Linux) от Саффорда и Зоара.TLC использует TPM controller, что приятно, но статья датирована 2005 годом, и я не смог найти текущие альтернативы.

Знаете ли вы другие варианты?

Обновить:А что касается других ОС?OpenSolaris?Семейство BSD?

Решение

В ДигСиг модуль ядра реализует проверку двоичных файлов, подписанных инструментом под названием bsign.Однако, начиная с версии 2.6.21 ядра Linux, над ним не проводилось никакой работы.

Другие советы

Я понимаю, что это древний вопрос, но я только сейчас нашел его.

Некоторое время назад я написал поддержку подписанных исполняемых файлов для ядра Linux (примерно версии 2.4.3), и у меня был весь набор инструментов для подписи исполняемых файлов, проверки подписей на execve(2) время, кэширование информации о проверке подписи (очистка проверки при открытии файла для записи или ином изменении), внедрение подписей в произвольные программы ELF и т.д.Это действительно приводило к некоторым потерям производительности при первом выполнении каждой программы (поскольку ядро должно было загружаться в весь файл, а не просто запрашивать страницу нужных страниц), но как только система находилась в устойчивом состоянии, она работала хорошо.

Но мы решили прекратить его разработку, потому что он столкнулся с несколькими проблемами, которые были слишком велики, чтобы оправдать сложность:

Мы еще не создали поддержку для подписанные библиотеки.Подписанные библиотеки потребовали бы также изменения ld.so загрузчик и dlopen(3) механизм.Это не было невозможно, но усложнило интерфейс:должны ли мы попросить загрузчик запросить у ядра проверку подписи или вычисления должны выполняться полностью в пользовательском пространстве?Как можно было бы защититься от strace(2)d обрабатывать, выполняется ли эта часть проверки в пользовательском пространстве?Будем ли мы вынуждены запретить strace(2) полностью на такой системе?

Что бы мы сделали с программы, которые предоставляют свой собственный загрузчик?
Великое множество программ написано на языках, которые не компилируются в объекты ELF.Нам нужно было бы предоставить специфичный для конкретного языка изменения в bash, perl, python, java, awk, sed, и так далее, чтобы каждый из переводчиков мог также проверка подписей.Поскольку большинство этих программ представляют собой обычный текст свободного формата, им не хватает структуры, которая позволяла так легко внедрять цифровые подписи в объектные файлы ELF.Где будут храниться подписи?В сценариях?В расширенных атрибутах?Во внешней базе данных подписей?
Многие переводчики являются широко открытый о том, что они позволяют; bash(1) может взаимодействовать с удаленными системами полностью сам по себе используя echo и /dev/tcp, и может быть легко обманом заставлен выполнить все, что нужно злоумышленнику.Подписанные или нет, вы не могли доверять им, когда они находились под контролем хакера.
Основным стимулом для поддержки подписанных исполняемых файлов являются руткиты, заменяющие предоставляемые системой /bin/ps, /bin/ps, /bin/kill, и так далее.Да, есть и другие полезные причины иметь подписанные исполняемые файлы.Однако со временем руткиты стали значительно более впечатляющими, поскольку многие полагались на ядро взломы, позволяющие скрыть свою деятельность от администраторов.Как только ядро будет взломано, вся игра закончится.В результате изощренности руткитов инструменты, которые мы надеялись предотвратить от использования, оказались в немилости у хакерского сообщества.
Интерфейс загрузки модуля ядра был широко открыт.Как только процесс имеет root привилегия, было легко внедрить модуль ядра без какой-либо проверки.Мы могли бы также написать другой верификатор для модулей ядра, но инфраструктура ядра вокруг модулей была очень примитивной.

Модель GNU / Linux / FOSS на самом деле поощряет вмешательство - в некотором роде.Пользователи и производители дистрибутивов должны иметь право свободно изменять программное обеспечение в соответствии со своими потребностями.Даже простая перекомпиляция программного обеспечения (без изменения какого-либо исходного кода) для настройки выполняется довольно часто, но может привести к нарушению подписи двоичного кода.В результате модель подписи двоичного кода не особенно хорошо подходит для GNU / Linux / FOSS.

Вместо этого этот вид программного обеспечения больше полагается на генерацию сигнатур и / или безопасных хэшей исходных пакетов.В сочетании с надежной моделью распространения пакетов, пользующихся доверием, это может быть сделано столь же безопасным (если не более того, с точки зрения прозрачности исходного кода), как и подписание двоичного кода.

Взгляните на это: http://linux-ima.sourceforge.net/

Он еще не подписан, но все еще позволяет проводить проверку.

Я могу ответить на этот вопрос с точки зрения ОС Solaris 10 и 11, все двоичные файлы подписаны.Для проверки подписи используйте 'elfsign'...

$ elfsign verify -v /usr/bin/bash
elfsign: verification of /usr/bin/bash passed.
format: rsa_sha1.
signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11.
signed on: Fri Oct 04 17:06:13 2013.

Oracle недавно добавила проверенный процесс загрузки и для Solaris 11, подробности см. - Введение в Верифицированную загрузку Solaris

Существует несколько форков кода OpenSolaris производственного уровня, три из которых заслуживают изучения - Illumos, SmartOS и OmniOS.

Взгляните на Медуза DS9.Я долго играл с ним (длинный) некоторое время назад, но, если я правильно помню, вы могли зарегистрировать определенные двоичные файлы, и любая модификация была запрещена на уровне ядра.Конечно, это можно переопределить с помощью локального доступа к компьютеру, но на самом деле это было не так-то просто.Есть умный демон по имени констебль, который проверяет все, что происходит на машине, и если происходит что-то необычное, он начинает кричать.

Я никогда не пробовал этого, но взгляните на : http://blog.codenoise.com/signelf-digitally-signing-elf-binaries.Решение работает без необходимости поддержки ядра и, похоже, готово к работе.

Код для подписывающего лица можно найти по адресу http://sourceforge.net/projects/signelf/

Это не решает вопрос "Запускать только доверенный код в Linux", но частично решает проблему, предоставляя программе возможность самостоятельно обнаруживать возможное вмешательство / повреждение

http://en.wikipedia.org/wiki/PKCS

Используйте для этого знак PKCS7 (S / MIME).Создайте свою собственную пару сертификат / закрытый ключ, самостоятельно подпишите сертификат, а затем подпишите свой файл закрытым ключом и сертификатом с помощью PKCS7.Он прикрепит к нему сертификат, а затем сможет проверить себя во время выполнения с помощью команды openssl (man smime или просто воспользуйтесь справкой openssl).Это защищено от несанкционированного доступа, потому что, даже если открытый ключ находится в файлах, которые вы предоставляете, подпись S / MIME для этого открытого ключа может быть сгенерирована только с помощью закрытого ключа, который вы не будете распространять.Таким образом, если файл подписан вашим сертификатом, он должен был быть подписан кем-то с закрытым ключом, и поскольку вы никому не давали закрытый ключ, он, должно быть, пришел от вас.

Вот как создать самозаверяющий сертификат.

http://www.akadia.com/services/ssh_test_certificate.html

Вам нужно будет убедить openssl доверять вашему сертификату как корню полномочий (-CAfile), затем проверить его с этим именем в качестве корня, а также проверить, что сертификат в файле принадлежит вам (хэшировать сертификат) и проверить хэш.Обратите внимание, что, хотя это не задокументировано, статус завершения openssl отражает действительность знака, который вы проверяете при выполнении smime verify.Это 0, если совпадает, ненулевое значение, если нет.

Обратите внимание, что все это небезопасно, потому что, если проверка есть в вашем коде, они могут просто удалить проверку, если захотят победить вас.Единственный безопасный способ сделать это - установить средство проверки в ОС, заставить его проверить ваш двоичный файл и отказаться от его запуска, если он не подписан.Но поскольку в ОС нет средства проверки, а linux в любом случае может быть изменен, чтобы удалить / обойти его...Для чего это действительно хорошо, так это для простого обнаружения поврежденных файлов, а не для того, чтобы помешать людям обойти вас.

Я согласен с тем, что философия, окружающая Linux, GNU и др.вращается вокруг переделки.С другой стороны, я также считаю, что некоторые системы заслуживают защиты от уязвимостей, таких как вмешательство в программное обеспечение, которое может подорвать конфиденциальность и целостность пользователей системы.

Реализации ядра не могут поспевать за быстрым циклом разработки самого ядра.Вместо этого я рекомендую реализовать форму проверки подписи исполняемого файла с помощью инструментов пользовательского пространства.Поместите исполняемые файлы в архив или образ файловой системы и подпишите образ с помощью закрытого ключа;если этот закрытый ключ остается на ваших компьютерах разработки (private), то при взломе вашего сервера злоумышленники все равно не смогут подписать свои собственные образы и внедрить свой код, не заставляя систему монтировать неподписанные образы.Он простирается дальше по цепочке:

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

Сделать все правильно - это нелегкое дело.Гораздо проще обойти все это, спроектировав свою систему в соответствии с другим подходом:

изолируйте пользователей от системы.Не предоставляйте пользователям средства для выполнения команд в вашей системе.Избегайте обстрела изнутри программ, которые полагаются на данные, предоставленные пользователем.
разработайте процедуры развертывания с помощью управления конфигурацией и убедитесь, что ваши развертывания "повторяемы", что означает, что они приводят к одному и тому же функциональному результату при их многократном развертывании.Это позволяет вам "сбивать ядерную бомбу с орбиты" на машинах, которые, как вы подозреваете, были скомпрометированы.
относитесь к своим машинам так, как если бы они были скомпрометированы:регулярно проводите аудиты для проверки целостности ваших систем.Сохраняйте свои данные на отдельных изображениях и регулярно повторно развертывайте системы.Подписывайте изображения и заставляйте системы отклонять неподписанные изображения.
используйте сертификаты:отдавайте предпочтение подходу "закрепления сертификата".Разверните корневой сертификат для своих приложений (который обеспечит автоматическое отклонение подписей, которые не были сертифицированы вашей организацией), но, по крайней мере, пусть система управляет отпечатками текущих изображений и уведомляет администраторов об изменении отпечатков пальцев.Хотя все это возможно реализовать с помощью цепочек ключей, аутентификация на основе сертификатов была разработана именно для этого приложения.

Мне нравится думать о безопасности как о цепи.Более слабое звено цепи может поставить под угрозу всю систему.Таким образом , все это становится "предотвращение получения неавторизованным пользователем пароля root".

Как предположил @DanMoulding, исходный код программного обеспечения также важен, и в будущем, вероятно, официальные магазины приложений для ОС станут стандартом.Подумайте о магазинах Play Store, Apple или Microsoft.

Я думаю, что установка и распространение скрытого вредоносного кода - это гораздо более коварная проблема.В конце концов, для загрузки неправильного кода это должно быть сначала установлено где-нибудь в системе.Больше уровней безопасность, конечно, обычно лучше.Вопрос в том,:стоит ли это того каких затрат?

На мой взгляд, ответ таков: "это зависит".Вы можете снизить риск, приняв набор политик безопасности, предложенных @sleblanc.Вы можете зашифровать свою файловую систему (https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup), используйте файловые системы, доступные только для чтения, для двоичных файлов или используйте механизм для подписи и проверки двоичных файлов.

Однако какой бы механизм вы ни использовали, вы ничего не сможете сделать, как только злоумышленник получит root-доступ.Инструменты проверки подписи могут быть заменены на измененную версию или просто отключены, и на самом деле не имеет значения, запускаются ли инструменты в пространстве пользователя или в пространстве ядра после того, как компьютер был скомпрометирован (хотя последнее, конечно, было бы более безопасным).).

Поэтому было бы неплохо, если бы ядро Linux могло встроить модуль проверки подписи и другой уровень безопасности между пользователем root и операционной системой.

Например, это подход, принятый на недавнем macOS Версии.Некоторые файлы не могут быть изменены (а иногда и прочитаны) даже учетной записью root, а также существуют ограничения на политики и модули ядра (напримерв систему может быть загружен только подписанный или авторизованный kext). Windows принял более или менее тот же подход с Блокировщик приложений.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow