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

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

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

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

Вы знаете другие варианты?

ОБНОВЛЕНИЕ: А насчет других ОС? OpenSolaris? Семья БСД?


person TH.    schedule 14.11.2009    source источник


Ответы (10)


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

person hillu    schedule 14.11.2009
comment
Этот ответ - то, что я ищу: двоичная сертификация на основе ядра. К сожалению, DigSig больше не поддерживается. Мой вывод таков: в настоящее время у нас нет решения производственного уровня для сертификации исполняемых файлов на основе ядра. Спасибо всем за обсуждение. - person TH.; 18.11.2009
comment
Возможно, DigSig можно портировать на последние версии ядра. Моя интуиция подсказывает мне, что управление ELF не могло сильно измениться за последние два года. - person hillu; 18.11.2009
comment
У @viraptor есть хороший ответ ниже, IMA, но мне пришлось выбрать только один. - person TH.; 18.11.2009
comment
Капут от 05 марта 2009 г. - person Falcon Momot; 21.10.2014

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

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

person sarnold    schedule 02.03.2012

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

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

person Dan Moulding    schedule 14.11.2009
comment
Спасибо за ваш ответ. Я не уверен, что обе вещи относятся к одной категории. Во время установки вы совершенно правы: требуется доверенная система пакетов. Но меня беспокоит время загрузки, т.е. программное обеспечение было подделано после установки (оно подделано, если сравнивать с программным обеспечением, подписанным доверенным дистрибутивом). Итак, я думаю, что мы говорим о взаимодополняющих проблемах. Например, TLC использует запечатанный главный ключ ядра, чтобы во время загрузки гарантировать, что загружаемое ядро ​​является доверенным. В нем используется микросхема TPM, поэтому аппаратное обеспечение помогает нам гарантировать, что с ядром все в порядке. - person TH.; 14.11.2009
comment
Что вы можете сделать достаточно хорошо, так это проверить двоичные файлы в каком-то закрытом домене (например, в вашей компании). Если у вас такая же настройка на 100+ хостах, то можно просто с помощью верификации проверить, что никто не менял данные на диске. Это похоже на Tripwire с аппаратной поддержкой. - person viraptor; 14.11.2009
comment
@TH: Извините, наверное, я неправильно понял ваш вопрос. Признаюсь, я только бегло просмотрел статью по TLC (она была длинной, и у меня нет времени ее читать сейчас). На первый взгляд, однако, я не уверен, что система целостности во время загрузки обеспечивает значительно лучшую безопасность, чем традиционные меры безопасности Unix. Я думаю, что гораздо более коварной проблемой является установка и распространение скрытого вредоносного кода. В конце концов, чтобы загрузить плохой код, он должен быть где-то установлен в системе. Конечно, чем больше уровней безопасности, тем лучше. Вопрос в том, стоит ли это затрат? - person Dan Moulding; 14.11.2009
comment
Этот ответ настолько неверен на многих уровнях - person A X; 12.06.2021

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

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

person viraptor    schedule 14.11.2009
comment
Спасибо. IMA выглядит живой инициативой (TLC и DigSig выглядят мертвыми). Это полезно для меня сейчас, и зрелая исполняемая подпись и проверка могут появиться в результате дальнейшего развития IMA. - person TH.; 18.11.2009

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

person Brainz    schedule 11.12.2014
comment
Я добавил проверенную загрузку в Solaris. Он проверяет RSA-подпись elfsign в подписанных модулях ядра перед загрузкой. Он также проверяет загрузочный блок SPARC (для SPARC) или загрузочные объекты GRUB (для безопасной загрузки X86 UEFI). Подтвержденная загрузка поддерживается в реальных (голых) средах и виртуальных машинах (т. е. LDoms — виртуальная машина Oracle — и зоны ядра Solaris). - person Dan Anderson; 17.09.2018

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

person Stefano Borini    schedule 14.11.2009

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

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

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

person Gabriel Mazetto    schedule 12.11.2012

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

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

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

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

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

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

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

person Bemipefe    schedule 01.03.2019

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. Это 0, если он совпадает, не ноль, если нет.

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

person Southern Hospitality    schedule 16.11.2009
comment
В этом ответе рассказывается, как подписывать и проверять подпись, но не о том, как гарантировать, что только проверенные подписанные исполняемые файлы выполняются ядром Linux. - person Jamey Hicks; 02.02.2010

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

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

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

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

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