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

Question

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

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

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

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

ОБНОВЛЕНИЕ : А по поводу других ОС? OpenSolaris? Семья BSD?

Answer 1

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

Некоторое время назад я написал подписанную поддержку исполняемых файлов для ядра 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 и т. Д. Да, есть и другие полезные причины иметь подписанные исполняемые файлы. Однако со временем руткиты стали значительно более впечатляющими: многие полагались на хаки kernel , чтобы скрыть свою деятельность от администраторов. Как только ядро ​​взломано, вся игра окончена. В результате изощренности руткитов инструменты, которые мы надеялись предотвратить использование, перестали пользоваться популярностью в сообществе хакеров.

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Он еще не подписан, но все еще включает проверку.

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

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

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

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

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

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

Answer 10

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

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

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

Получить все правильно - трудное дело. Намного проще обойти все это, спроектировав вашу систему по другому подходу:

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