Библиотека dylib не загружена из-за ограниченного двоичного кода после подписания кода Apple

Я помещаю исполняемый двоичный файл XXX в свое приложение, работающее на MacOS, и подписываю его кодом. Мое приложение будет использовать эту службу через порт.

Исполняемый двоичный файл XXX зарегистрирует службу через файл plist после установки моего приложения, файл plist содержит DYLD_LIBRARY_PATH, который сообщает исполняемому двоичному файлу, где найти dylib для использования.

launchctl load -wF "$ HOME / Библиотека / LaunchAgents / local.plist"

launchctl запускать локально

Вот в чем проблема:

он работал нормально после того, как я создал приложение.

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

dyld: Library not loaded: @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib
Referenced from: /Users/buffer/Library/Application Support/XXX
Reason: unsafe use of relative rpath @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib in /Users/buffer/Library/Application Support/XXX with restricted binary

Он будет использовать путь к dylib по умолчанию （@@ HOMEBREW_PREFIX @@ / opt / libev / lib / libev.4.dylib）, который поступает из исполняемого двоичного файла XXX, не из моего пользовательского DYLD_LIBRARY_PATH. Apple ограничила двоичное использование такого небезопасного относительного пути rpath.

Обновлено:

Мое приложение запустит сценарий оболочки для установки исполняемого двоичного файла XXX и dylib, исполняемый двоичный файл XXX зарегистрируется как служба для запуска и остановки через plist, как показано ниже.

launchctl load -wF "$ HOME / Библиотека / LaunchAgents / local.plist"

launchctl запускать локально

Мой исполняемый двоичный путь XXX и DYLD_LIBRARY_PATH оба расположены в / Users / buffer / Library / Application Support / myApp / ***, он запускается отдельно как служба для моего приложения.

Я обнаружил несколько ситуаций ниже:

1. У меня такой же исполняемый двоичный файл XXX, подписанный 25 сентября 2018 г., он работает нормально.

2. И исполняемый двоичный файл XXX, который не был подписан, тоже работал нормально.

3. Но когда я сейчас подписал исполняемый двоичный файл XXX и буду использовать его с dylib, он получит ошибку, указанную выше.

Итак, изменился ли алгоритм подписи яблока и возникает ли эта ошибка? вот моя команда подписи кода на данный момент, как показано ниже:

codeign --force --options runtime --sign "Developer ID Application: ****" XXX

Наконец:

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

Мое разрешение на использование переменных среды DYLD отключено по умолчанию

вы можете проверить этот документ ниже

Защищенные права времени выполнения

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

codesign --force --options runtime --entitlements /Users/buffer/Desktop/entitlements.plist  --sign "Developer ID Application: ****" XXX

macos ios swift code-signing
person Buffer    schedule 27.08.2019    source источник
comment
Покажите свои права.   -  person El Tomato    schedule 27.08.2019
comment
Спасибо за ответ, я нашел причину   -  person Buffer    schedule 27.08.2019
comment
Спасибо за ваш пост, --options runtime работал у меня.   -  person Thanh Dat Nguyen    schedule 02.12.2019

Ответы (2)


arrow_upward
5
arrow_downward

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

/System/
/usr/bin/
/Library/Frameworks/

Документация для подписи кода под названием «Проверка соответствия привратника "прямо заявляет, что:

Начиная с macOS 10.10.4, Gatekeeper проверяет, что библиотеки не загружаются из-за пределов пакета приложений. Если приложение использует @rpath или абсолютный путь для связи с динамической библиотекой вне приложения, Gatekeeper отклоняет приложение. Это ограничение распространяется на основной исполняемый файл приложения и любой другой исполняемый файл в пакете, включая библиотеки. Это ограничение применяется, даже если путь не существует (что обычно заставляет динамический компоновщик откатиться к библиотеке внутри пакета). Ошибка появится в системном журнале с сообщением, подобным приведенному ниже, для приложения MyApp.app, пытающегося установить связь с библиотекой libLibrary.dylib в нестандартном месте /foo

Таким образом, вам следует встроить свой дилиб в свое приложение.

По-видимому, еще одно возможное решение - использовать подписанный установщик для установки общей платформы на /Library/Frameworks/, но это решение было предложено DTS и, по-видимому, не является частью официальной документации.

person jvarela    schedule 27.08.2019
comment
Упоминается ли это где-нибудь в документации Apple? - person Kamil.S; 27.08.2019
comment
Спасибо за ответ, я обновил некоторые ситуации выше. Тот же исполняемый двоичный файл XXX, подписанный 25 сентября 2018 года, работает нормально. пожалуйста, проверьте. - person Buffer; 27.08.2019
comment
Для включения загрузки подписанных / неподписанный код извне вашего приложения. - person rcoup; 06.04.2021
comment
Верно, но этого следует по возможности избегать, поскольку вы ставите под угрозу безопасность своего приложения. - person jvarela; 06.04.2021

arrow_upward
2
arrow_downward

Я узнал от Apple DTS, что есть известная ошибка в macOS Catalina 10.15.3 и ранее (уже исправленная в бета-версии 10.15.4), в которой нотариально заверенное приложение командной строки, которое ссылается на .dylib вне его пакета (и приложения командной строки обычно не в комплекте) все равно не пройдут проверки гейткипером, которые запускаются, когда в исполняемом файле командной строки установлен флаг карантина.

Чтобы обойти проблему, Apple DTS рекомендует:

Самый простой обходной путь - подписать инструмент с помощью флагов усиленной среды выполнения и проверки библиотеки.

То есть измените вызов codesign с этого:

% codesign -s …stuff… -o runtime …stuff… helloworld

к этому:

% codesign -s …stuff… -o runtime,library …stuff… helloworld

Явная установка флага библиотеки отключает эту проверку привратника и позволяет вашему инструменту работать в macOS 10.15. {0,1,2,3}. Пожалуйста, обратите внимание на то, чтобы удалить этот флаг, как только 10.15.4 будет выпущена и широко распространена.

person Bill Feth    schedule 11.03.2020