Google рекомендует сокращать поверхность атаки графических процессоров в Android, ограничивая команды IOCTL, которые приложениям не нужны в производственной среде, вместо того чтобы полагаться только на обнаружение и устранение отдельных уязвимостей. Эта практика стала результатом сотрудничества команды Android Red Team и компании Arm по анализу Mali GPU и его драйвера с акцентом на предотвращение доступа к ненужным функциям с помощью SELinux.
Этот шаг имеет важное значение для безопасности, поскольку графический процессор стал привлекательной целью для злоумышленников из-за своей сложности и наличия повышенных привилегий внутри системы. Согласно материалу, с 2021 года большинство эксплойтов, основанных на драйверах ядра Android, было нацелено на графический процессор, а атаки в основном концентрировались на интерфейсе между драйвером пользовательского режима, известным как UMD, и привилегированным драйвером режима ядра, или KMD.
Почему сокращение поверхности атаки является приоритетом?
Вредоносные входные данные, проходящие через этот интерфейс, могут эксплуатировать дефекты, приводящие к повреждению памяти. Google считает, что сделать ненужные пути недоступными — это эффективный и зачастую более быстрый способ повысить уровень защиты наряду с продолжением поиска и устранения программных ошибок.
Совместный анализ с Arm охватывал драйвер Mali, используемый примерно в 45% устройств Android, и помог определить части поверхности атаки, представляющие угрозу безопасности, но не требующиеся для работы устройств в производственной среде. Поэтому политика была сосредоточена на командах IOCTL, которые представляют собой ввод и вывод драйвера графического процессора и, следовательно, являются важной частью поверхности атаки.
В предлагаемом подходе команды Mali разделяются на три категории:
- Неограниченные команды: необходимы для нормальной работы и остаются доступными приложениям.
- Команды измерения и инструментов: используются средствами анализа производительности и отладки для мониторинга работы графического процессора.
- Ограниченные команды: не должны использоваться производственными приложениями и включают команды, предназначенные для разработки графического процессора, а также устаревшие команды, которые больше не используются в текущей версии UMD устройства.
Политика направлена на блокировку устаревших и отладочных команд в производственной среде, ограничивая команды измерения оболочкой или приложениями с признаком отладки. Производственные команды остаются доступными обычным приложениям.
Поэтапное внедрение политики SELinux
Google выбрала поэтапный подход, чтобы снизить вероятность нарушения работы легитимных приложений. Процесс начался с необязательной политики: был создан новый атрибут SELinux под названием gpu_harden, блокирующий команды измерения, после чего его применили к ограниченному набору системных приложений для проверки последствий. На этом этапе правило allowxperm использовалось для регистрации попыток доступа вместо их немедленной блокировки, а затем анализировались журналы отказов, чтобы убедиться в отсутствии сбоев.
После подтверждения безопасности подхода политика перешла к более строгой модели, используемой по умолчанию, с созданием домена gpu_debug, разрешающего доступ к командам измерения. Таким образом, приложения по умолчанию оказались защищены, а разработчикам были предоставлены исключения в определённых случаях:
- запуск приложения на устройстве с root-привилегиями;
- установка свойства android:debuggable="true" в манифесте приложения;
- запрос постоянного исключения в политике SELinux приложения.
Шаги по применению политики на устройствах
Google предоставляет рекомендации, чтобы помочь партнёрам и более широкой экосистеме внедрить аналогичный механизм, отделяя логику общей политики от особенностей каждого устройства или драйвера. Процесс начинается с использования общего макромодуля на уровне платформы Android в составе system/sepolicy. Этот модуль находится в файле /sepolicy/public/te_macros и позволяет политикам устройств передавать списки команд IOCTL, которые следует фильтровать.
Модуль разработан так, чтобы разрешать всем приложениям, или appdomain, доступ к списку неограниченных команд и ограничивать чувствительные команды измерения инструментами отладки, такими как shell или runas_app, когда приложение доступно для отладки. Он также блокирует команды с повышенными привилегиями в зависимости от целевой версии SDK приложения, сохраняя совместимость со старыми приложениями.
Затем разработчик устройства создаёт файл ioctl_macros в каталоге политики SELinux устройства, например device/your_company/your_device/sepolicy/ioctl_macros, а затем определяет списки команд для драйвера графического процессора. Google рекомендует иметь как минимум отдельные списки производственных команд, команд измерения и отладочных команд, включающие шестнадцатеричные номера IOCTL драйвера.
Arm предоставила официальную классификацию собственных команд IOCTL в файле Documentation/ioctl-categories.rst в версии r54p2, отметив, что список будет обновляться вместе с будущими версиями драйверов.
Тестирование перед принудительным применением
На следующем этапе политика применяется к узлу устройства графического процессора посредством создания файла gpu.te в каталоге политики устройства, после чего вызывается общий макромодуль и ему передаются метка устройства и заранее определённые списки IOCTL.
Google подчёркивает, что разработка политики SELinux должна оставаться итеративным процессом, включающим тестирование, отладку, а затем принудительное применение. Такой подход позволяет собирать данные о реальном использовании, выявлять случаи, которые могут потребовать исключений, и постепенно расширять область действия политики вместо введения широких ограничений с самого начала.
Google считает, что сокращение поверхности атаки защищает не только от известных уязвимостей, но и может сделать ещё не обнаруженные уязвимости или уязвимости, которые могут появиться в будущем, недоступными через ограниченные пути. Расширение этого подхода требует сотрудничества между Android, производителями устройств и партнёрами экосистемы, а команды безопасности Android заявили о своей приверженности поддержке более широкого внедрения этих мер.