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

Ответ 1

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

Ответ 2

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

Я написал подписанную исполняемую поддержку ядра 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, легко вводить модуль ядра без какой-либо проверки. Мы могли бы написать еще один верификатор для модулей ядра, но инфраструктура ядра вокруг модулей была очень примитивной.

Ответ 3

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

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

Ответ 4

Посмотрите на это: http://linux-ima.sourceforge.net/

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

Я могу ответить на вопрос с точки зрения ОС 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.