Выпускалась ли статья о том, как именно работает SuperSu? После некоторого поиска я нашел в основном руководства по использованию приложения, а не детали реализации.
Однако я нашел этот ресурс, который в основном направлен на объяснение того, как использовать привилегии суперпользователя программно, но объяснил все достаточно хорошо. Статья дает информацию о SELinux, но не столько о том, как можно обойти его принудительное применение.
Похоже, что существует много переключений контекста, позволяющих выполнять определенные события (с точки зрения тех, кто использует SuperSu), которые в противном случае запрещены в SELinux, но как SuperSu дошел до точки, в которой он мог « легально », как что касается SELinux, исправить SELpolicies?
Кажется, что цель состоит в том, чтобы заставить процесс инициализации порождать новую оболочку, которая запускает демон su, но, похоже, нет никаких исправлений процесса инициализации , но из статьи по ссылке:
В прошивках, использующих SELinux, su обычно реализуется как прокси для демона, запускаемого из init.
и
Вы можете задаться вопросом, почему - если мы уже работаем как контекст инициализации, как пользователь root...
тл; др ; Как SuperSu выполняется в контексте процесса инициализации?
Дано как:
u:r:init:s0 - Highest init context
u:r:init_shell:s0 - Shell started from init
SuperSU больше не развивается активно, новым преобладающим стандартом является Magisk, который изначально был основан на SuperSU (идеи и, возможно, некоторый код), но теперь он продвинулся далеко вперед. Так что лучше по возможности использовать новое активно поддерживаемое решение с открытым исходным кодом. Или, если вы хотите приключений, попробуйте это: Как вручную рутировать телефон? .
Мой ответ на Как работает Magisk? охватывает почти все внутренности SuperSU, а также некоторые дополнительные детали, которые не применимы к SuperSU. Давайте не будем усложнять.
0):Android основан на ядре Linux, которое при загрузке устройства запускается от имени пользователя root. Пространство ядра для нас невидимо — пространство пользователя . initэто первый процесс, запущенный ядром, который мы видим, он также работает с root-доступом. Он запускает множество служб/демонов (ОС), многие из них также работают с привилегиями root. Наконец, когда все необходимые процессы запущены, initнас перебрасывает к процессу без полномочий root (непривилегированному) — оболочке в стандартных ОС Linux, приложению Launcher или экрану блокировки (которое также является приложением System UI ) на Android. Корень — это уважаемый пользователь ядра — суперпользователь — идентифицируемый по идентификатору пользователя . 0. Ядро никогда не запрещает ему причинять какой-либо вред или пользу чему-либо на устройстве. Непривилегированным пользователям назначаются UID 1( 65534обычно). Android разделяет эти UID для разных категорий приложений и процессов, как описано здесь . Каждый процесс и каждый файл имеют UID , G roup ID , дополнительные группы и режим разрешений . Эти четыре параметра определяют, как процесс получает доступ к другим процессам и файлам. Весь этот феномен называется дискреционным контролем доступа .
Если непривилегированный процесс хочет получить доступ к какому-либо файлу или выполнить какое-либо действие, которое разрешено только пользователю root, первый должен переключиться на второго. Это делается путем выполнения файла (обычно su), который либо имеет set-user-id-root , либо имеет возможностиsetuid / segid file . Возможность — это подмножество полномочий пользователя root. Исполняемый файл выполняет системный вызовsetuid поэтому ядро повышает непривилегированное состояние до привилегированного. Это упрощение, на самом деле здесь задействовано множество других факторов. Но на Android приложения запускаются путем отказа от всех возможностей и привилегий таким образом, что они не могут каким-либо образом повысить свои привилегии (за исключением уязвимостей). Таким образом, непривилегированное приложение запрашивает какой-либо другой уже запущенный привилегированный процесс для выполнения привилегированной задачи от имени первого. Привилегированный процесс называется daemonsu(или magiskd), и запрос перенаправляется, когда приложение выполняет специальный suдвоичный файл, который взаимодействует с приложением SuperSU, чтобы запросить у пользователя-человека разрешение.
В дополнение к DAC в Android также используется SELinux — обязательный элемент управления доступом . Как и в случае с DAC, каждый процесс и каждый файл помечаются контекстом SELinux, и определяется политика, обеспечивающая широкий спектр взаимодействий между контекстами/метками. Политика не содержит Super Context , поэтому каждый процесс (даже работающий с UID ) имеет некоторые ограничения. Но его нужно запускать с полностью неограниченным контекстом, который должен быть определен до установки SELinux ( на очень ранней стадии загрузки), потому что после этого нет возможности установить его или изменить политику. Некоторые поставщики строят свои ядра без0daemonsuenforcinginitpermissiveSECURITY_SELINUX_DEVELOP, так что SELinux применяется ядром — даже раньше. В этом случае ядро необходимо пересобрать/пропатчить. Смотрите подробности в этом ответе .
При прошивке SuperSU.zip:
/sepolicyфайл с полностью разрешительным u:r:supersu:s0контекстом ( supersuможет быть другим, я не могу вспомнить, что SuperSU использовал в последних выпусках, сейчас использует Magisk u:r:magisk:s0).initслужбу в /init.rcфайл, который начинается daemonsuс 0контекста UID/GID и SELinux u:r:supersu:s0после /dataмонтирования (или даже раньше).Оба файла sepolicyи init.rcбыли частью ramdiskвнутренней части boot.img(которая также содержит двоичный файл ядра), но с Treble, SAR и A/BPartitions они могут находиться в разных местах. Таким образом, Magisk использует разные подходы для разных устройств, но концепция одна и та же.
Оба шага также могут быть заменены заменой фактического /initдвоичного файла пользовательским init, который берет на себя процесс загрузки, исправляет sepolicyи запускает службу на ходу перед выполнением фактического файла init.
Другие вещи, которые непосредственно связаны с процессом рутирования, включают разблокировку загрузчика, boot.imgраспаковку/переупаковку, отключение Verified Boot ( dm-verity) и FDE/FBE , исправление ядра для загрузки по-другому init(или для отключения механизмов безопасности конкретного поставщика), бессистемное рутирование, (не)установку Android свойства, каталоги монтирования привязки, изоляция пространств имен монтирования и т. д.
Эндрю Т.
ШерреллБК
ханшенрик
Ирфан Латиф