Binder использует модель безопасности на основе возможностей.Каждый связующий объект представляет собой возможность;передача этого объекта другому процессу предоставляет процессу доступ к этой возможности.С этой точки зрения вы предотвращаете атаки человека в середине, не передавая важный объект связующего человеку человеку в середине.Если процесс не получает объект связывания, он не может получить к нему доступ каким-либо образом.
Относительно проблемы «подделки перекрестных ссылок», обсуждаемой в документе, если я понимаю конкретный сценарий, который ониЯ думаю, что их приложение о пользовательском пространстве немного слабее, чем я бы с этим согласился.Они делают ошибку, я думаю, глядя на специальный код C, написанный для ServiceManager.Формально я бы рассматривал код пространства пользователя C ++ (состоящий, в частности, из Parcel) как часть архитектуры Binder.Этот код, в частности, гарантирует, что он будет иметь дело с такими попытками подделки, когда вы вызываете его readBinder () и связанные с ним методы.
Я не согласен с утверждением, что это недостаток, заключающийся в том, что ядро не полностью обеспечиваетцелостность данных.Единственный способ сделать это - представить стандартную типизированную структуру данных для транзакций связывания, чтобы она могла считывать и проверять содержимое посылки.По моему мнению, это приводит к слишком большим знаниям в ядре и не приносит никакой реальной выгоды.Независимо от того, сколько вы там поместите, пользовательскому пространству потребуется выполнить некоторую проверку входящей транзакции, чтобы убедиться, что она соответствует ее ожиданиям.Сегодня это делается на уровне проверки того, что примитивные операции чтения данных в Parcel (readBinder (), readString16 (), readInt () и т. Д.) Записываются во избежание атак.Для большей проверки ядра все еще потребуется проверка правильности типов данных в пользовательском пространстве, и теперь вы фактически перенесли некоторые возможности для атак (из-за ошибок в этом коде) из пользовательского пространства в ядро.
И последнее, что касается безопасности связующего, - это то, что важно понимать, что на уровне платформы существует еще одна важная модель безопасности, реализованная поверх инфраструктуры связующего.Это система, основанная на разрешениях / uid, где службы могут проверять uid входящих вызовов, чтобы проверить их по разрешенным разрешениям.
Эта модель безопасности имеет еще одну уязвимость подделки, с которой она должна иметь дело.Типичным сценарием может быть приложение, получающее IBinder для службы диспетчера операций (поскольку каждый может получить это).API Сервиса Activity Manager глубоко основан на проверке uid входящих вызовов, чтобы определить, что разрешено - например, если сделан вызов bindService (), он проверит, имеет ли этот uid разрешение на привязку кданный сервис.Вредоносное приложение может попытаться сыграть в игры, передав диспетчер операций IBinder другой системной службе, например, как IWindow диспетчеру окон.Если он знает транзакции, которые совершит вторая системная служба, он может настроить все так, чтобы он выполнял вызов, который, по его мнению, называется resizeWindow (), но фактически превращается в вызов bindService (), когда он помещается в действиеменеджер (если эти два вызова сопоставлены с одним и тем же идентификатором транзакции).
Эта уязвимость существует из-за того, что система связывания не вводится каким-либо образом, вызовы «метода» - это просто транзакции, отправляемые с целочисленным кодом транзакции ибуфер данных.
Для защиты от этого интерфейсы с типом пользовательского пространства, созданные с помощью aidl, всегда помещают в начале буфера транзакции имя интерфейса, который они намереваются вызвать, и получающий код транзакции проверяетимя интерфейса в начале буфера, чтобы убедиться, что оно соответствует его собственному взаимодействию.Таким образом, спуфер в вышеописанном сценарии будет обнаружен, когда менеджер активности обнаружит, что у него есть входящий вызов, интерфейс которого был для окна.
В любом случае, для практического использования разработчиками Android безопасность на основе uid так же актуальна, как и модель возможностей связующего ядра. В некоторых случаях вы будете обеспечивать безопасность, ограничивая, какие процессы получают доступ к подшивке. Примером этого может служить наличие IBinder, представляющего каждое действие, которое разделяют только системный процесс и процесс, выполняющий операцию.
В других случаях объект IBinder будет предоставлен всем заинтересованным процессам, но обеспечит безопасность в точке вызова на основе uid. Если вы используете aidl для предоставления своей стандартной реализации таких интерфейсов, ваша собственная реализация такой безопасности может быть реализована в зависимости от того, какое значение вы хотите применить к uids. Например, вы можете использовать стандартное средство для связывания разрешений с uid и спрашивать у менеджера пакетов, есть ли у входящего uid разрешение.