2013-04-24 2 views
3

Я хочу открыть общий объект в качестве файла данных и выполнить проверку проверки на нем. Проверка - проверка подписи, и я подписываю общий объект. Если проверка выполнена успешно, я хотел бы загрузить открытый в данный момент общий объект в качестве надлежащего общего объекта.Позвоните в dlopen с файловым дескриптором?

Первый вопрос: можно ли позвонить dlopen и загрузить общий объект в качестве файла данных во время проверки подписи, чтобы код не был выполнен? Согласно страницам man, я не верю, так как я не вижу флаг, похожий на RTLD_DATA.

Поскольку у меня есть открытый объект как файл данных, у меня есть дескриптор. После успешной проверки я хотел бы передать дескриптор в dlopen, чтобы динамический загрузчик правильно загрузил общий объект. Я не хочу закрывать файл, а затем повторно открывать его через dlopen, потому что он может ввести условие гонки (где проверенный файл не является тем же файлом, который был открыт и выполнен).

Второй вопрос: как передать открытый файл dlopen с использованием файлового дескриптора, чтобы dlopen выполнял обычную инициализацию общего объекта?

+0

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

+0

Вы сделали ** не ** определите свое понятие «одобренный» или «аутентичный». У вас может быть некоторый независимый способ хранения хэша «хороших» плагинов в другом месте (например, базы данных, файла конфигурации) и проверки хэш-кода плагина перед 'dlopen'. Тем не менее, вероятно, нет возможности быть отказоустойчивым. В противном случае вы также можете генерировать C-код плагина, выполнять все проверки, которые вы хотите во время этого поколения C, затем скомпилировать его и «dlopen».FWIW [GCC MELT] (http://gcc-melt.org/) делает это. –

+0

Измените свой вопрос, чтобы улучшить его. –

ответ

3

В Linux вы, возможно, могли бы dlopen файл /proc/self/fd/15 (для дескриптора файла 15).

RTLD_DATA не похоже существует. Поэтому, если вы этого хотите, вы должны исправить свой собственный динамический загрузчик. Возможно, сделать это в пределах MUSL Libc может быть менее сложно. Я до сих пор не понимаю, зачем вам это нужно.

Как-то вы должны доверять плагину dlopen -ed (и он будет запускать свои функции-конструкторы на dlopen раз).

Вы можете проанализировать общий объект плагин, прежде чем dlopen -ную его с помощью некоторых ELF разборе библиотеки, возможно, libelf или libbfd (от binutils); но я до сих пор не понимаю, какой анализ вы хотите сделать (и вы действительно должны это объяснить, в частности, что произойдет, если плагин косвенно связан с каким-то программным обеспечением для плохого поведения). Другими словами, вы должны больше объяснить свой шаг проверки. Обратите внимание, что общий объект может быть перезаписан сам.

В качестве альтернативы, не используйте dlopen и просто mmap ваш файл (вам нужно будет разобрать некоторый ELF).

Возможно, использование методов JIT generation может быть полезно (вы бы JIT сгенерировали код из некоторого данных, подтвержденных), например. с GCCJIT, LLVM, или libjit и т. д.

И если у вас есть два дескриптора файла для одного и того же общего объекта, у вас, вероятно, не будет никаких условий гонки.

+1

Привет Basile. «Вы должны как-то доверять плагину dlopen-ed». На самом деле мы этого не делаем. Доверие - это то, что мы используем, когда у нас нет эффективных средств контроля безопасности. В этом случае у меня есть как минимум два элемента управления: (1) проверка подписи; или (2) URL автоидентификации. – jww

+0

«RTLD_DATA, похоже, не существует». Да, правильно (это то, что я хотел бы использовать для простоты, если бы оно существовало). – jww

+0

«... вы, вероятно, могли бы распаковать файл/proc/self/fd/15». Это умно. Я попробую, когда у меня появится шанс. – jww

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