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

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

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

Я прочитал работу van Doom и др., Разработка и внедрение подписанных исполняемых файлов для Linux и IBM TLC (Trusted Linux Client) от Safford & Zohar. TLC использует контроллер TPM, что хорошо, но документ с 2005 года, и я не смог найти существующие альтернативы.

Знаете ли вы еще один вариант?

ОБНОВЛЕНИЕ: И о других ОС? OpenSolaris? Семейство BSD?

источник

2009-11-14 TH.

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

источник

2009-11-14 18:03:54 hillu

Этот ответ - это то, что я ищу: двоичная сертификация на основе ядра. К сожалению, DigSig больше не поддерживается. Мой вывод заключается в том, что в настоящее время у нас нет решения на уровне производства на основе исполняемого сертификата на основе ядра. Спасибо всем за обсуждение. –

Возможно, можно перенести DigSig на последние версии ядра. Чувство моего чувства говорит мне, что обработка ELF не могла сильно измениться за последние два года. – hillu

@viraptor имеет приятный ответ ниже, IMA, но я должен был выбрать только один. –

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

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

источник

2009-11-14 15:57:26

Спасибо за ваш ответ. Я не уверен, что обе вещи находятся в одной категории. Во время «времени установки» вы совершенно правы: требуется надежная система пакетов. Но меня беспокоит «время загрузки», т. Е. Программное обеспечение было изменено после установки (оно подделано, если сравнивать с доверенным дистрибутивом, подписанным программным обеспечением). Поэтому я думаю, что мы говорим о дополнительных проблемах. Например, TLC использует закрытый мастер-ключ ядра, чтобы гарантировать, что во время загрузки загружаемое ядро является надежным. В нем используется чип TPM, поэтому аппаратное обеспечение помогает нам гарантировать, что ядро в порядке. –

Что вы можете сделать довольно хорошо, хотя это проверка двоичных файлов в некотором закрытом домене (например, ваша компания). Если у вас есть одна и та же настройка на 100+ хостах, вы можете просто использовать проверку, чтобы проверить, что никто не изменил данные на диске. Это похоже на аппаратную поддержку Tripwire. – viraptor

+1, Лучший ответ –

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

источник

2009-11-14 16:15:36

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

Это еще не подпишу, но она по-прежнему обеспечивает проверку.

источник

2009-11-14 16:22:44 viraptor

Спасибо. IMA выглядит «живой» инициативой (TLC и DigSig выглядят довольно «мертвыми»). Это полезно для меня сейчас, и зрелое подписание и верификация исполняемого файла может возникнуть из дальнейшего развития IMA. –

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 может быть изменен, чтобы удалить/обойти его в любом случае ... То, что это действительно хорошо, - это просто обнаружение поврежденных файлов больше, чем попытка удержать людей от обхода вас.

источник

2009-11-16 05:04:40

В этом ответе указывается, как подписывать и проверять подпись, но не следует гарантировать, что ядро linux выполняется только проверенными, подписанными исполняемыми файлами. –

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

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

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

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

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

Интерфейс загрузки модуля ядра был широко открытым. Как только у процесса есть привилегия root, было легко вводить модуль ядра без какой-либо проверки. Мы могли бы написать еще один верификатор для модулей ядра, но инфраструктура ядра вокруг модулей была очень примитивной.

источник

2012-03-02 02:53:00 sarnold

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

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

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

источник

2012-11-12 11:03:21

Я могу ответить на вопрос с 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 Verified Boot Introduction

Есть некоторые производства класса вилы кода OpenSolaris , три исследования - Illumos, SmartOS и OmniOS.

источник

2014-12-11 13:20:52 Brainz

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

ответ

Смежные вопросы