Uid gid android это

Русские Блоги

Android-UID обучения, GID, GIDS и PID в системе Android

UID, GID, GIDS и PID в системе Android

вAndroidВ верхней части пользовательский UID указывает приложение. Когда приложение установлено, пользовательский UID назначается. В течение времени жизни приложения на устройстве пользовательский UID остается неизменным. Для обычных приложений GID равен UID.

GIDS генерируется платформой в процессе установки приложения и связана с конкретными разрешениями, применяемыми приложением. Если соответствующее разрешение, примененное в Приложении, предоставлено, и существует соответствующий GIDS, то gids этого Приложения будет содержать эти gids. Помните, что разрешения (GIDS) предназначены для разрешения или ограничения доступа приложений (не пользователей) к ресурсам устройства.

Android использует концепцию «песочницы» для достижения разделения и разрешений между приложениями, чтобы разрешить или запретить приложению доступ к ресурсам устройства, таким как файлы и каталоги, сети, датчики и API. Для этого Android использует некоторые утилиты Linux (такие как безопасность на уровне процесса, идентификаторы пользователей и групп, связанные с приложением, а также разрешения) для реализации операций, которые разрешено выполнять приложению.

Рисунок 1. Два Android-приложения, каждое в своей базовой песочнице или процессе

Приложения Android работают на собственных процессах Linux и им присваивается уникальный идентификатор пользователя. По умолчанию приложениям, работающим в базовом процессе изолированной программной среды, не назначаются разрешения, поэтому такие приложения имеют ограниченный доступ к системе или ресурсам, а приложения Android могут запрашивать разрешения только через файл манифеста приложения.

Различные приложения могут работать в одном процессе. Для этого метода вы должны сначала подписать эти приложения одним и тем же закрытым ключом, а затем использовать файл манифеста, чтобы назначить им один и тот же идентификатор пользователя Linux. Это делается путем определения атрибута манифеста android: sharedUserId с тем же значением / именем для общего доступа Доступ к его данным и коду, как показано на рисунке 2

Рисунок 2. Два приложения Android, запущенные в одном процессе

подводить итоги

В Android приложение имеет только один UID, и, конечно, несколько приложений могут также использовать UID.

Для обычных приложений gid равен uid. Поскольку uid и gid каждого приложения различны, как собственный уровень, так и уровень java могут защищать личные данные.

GIDS эквивалентен набору разрешений, UID может быть связан с GIDS, указывая, что UID имеет несколько разрешений

Процесс — это песочница хост-приложения, которое обычно имеет UID и несколько GIDS. Каждый процесс может получать доступ только к файлам в пределах диапазона разрешений UID и интерфейсов, разрешенных GID, которые составляют основную основу безопасности Android.

Источник

Русские Блоги

Об использовании android: sharedUserId = «android.uid.system»

Иногда нам нужно использовать некоторые системные разрешения в наших приложениях, такие как разрешения USB. Если процесс нашего собственного приложения и системный процесс имеют одинаковый UID, у нас будет это разрешение по умолчанию, и его не нужно предоставлять пользователю. Во многих случаях Так будет намного удобнее. Это разрешение используется в большинстве проектов, над которыми я недавно работал. Измените системное время, вызовите скрытый метод, выключите и перезапустите систему, установите, обновите и удалите приложения в автоматическом режиме и т. Д. Вначале добавьте разрешение напрямую и запустите его. Если сообщается об ошибке, независимо от симулятора или реальной машины, вы всегда будете получать сообщение «Невозможно открыть драйвер сигнализации: разрешение отклонено» в logcat. Для использования этой функции требуется разрешение root или она запускается в системном процессе.

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

Один из них — скомпилировать с помощью make в среде исходного кода системы Android:

1. Добавьте атрибут android: sharedUserId = «android.uid.system» в узел манифеста в AndroidManifest.xml приложения. .

2. Измените файл Android.mk и добавьте строку LOCAL_CERTIFICATE: = platform.

3. Используйте команду mm для компиляции, и сгенерированный apk будет иметь право изменять системное время.

Этот метод не может быть скомпилирован с .mk, поэтому я должен обратиться ко второму методу:
1. Добавьте атрибут android: sharedUserId = «android.uid.system». ,

2. Используйте eclipse для компиляции неподписанного файла apk, но этот файл apk использовать нельзя.

3. Используйте ключ платформы целевой системы, чтобы повторно подписать файл apk.

Этот шаг более сложен, сначала найдите файл ключа, расположение в моем каталоге исходного кода Android — «build / target / product / security»,

Следующие два файла — это platform.pk8 и platform.x509.pem. Затем используйте инструмент Signapk, предоставляемый Android, чтобы подписать,

Исходный код signapk находится в папке «build / tools / signapk», используется «signapk platform.x509.pem platform.pk8 input.apk output.apk»,

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

Наконец, чтобы объяснить принцип, сначала добавьте атрибут android: sharedUserId = «android.uid.system».

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

Затем сопоставьте UID программы с android.uid.system, то есть позвольте программе работать в системном процессе, чтобы у вас было право изменять системное время.

Недостаточно просто добавить UID. Если APK-файл установлен в это время, он не будет установлен, а подпись не будет совпадать.

Причина в том, что программа хочет запускаться в системном процессе, но также имеет ключ платформы целевой системы, которым являются два файла platform.pk8 и platform.x509.pem, упомянутые во втором методе выше.

После подписания этими двумя ключами apk фактически может быть помещен в системный процесс. Добавление LOCAL_CERTIFICATE: = platform к первому методу фактически использует эти два ключа для подписи.

Также существует проблема, то есть программа, сгенерированная таким образом, может использоваться только в исходной системе Android или системе, скомпилированной вами, потому что такая система может получить два файла platform.pk8 и platform.x509.pem.

Если Android, сделанный другой компанией, даже не может быть установлен. Попробуйте подписать ключ в исходном Android, программа работает на эмуляторе ОК, но при установке на G3 сразу же выдается запрос «Пакет . не имеет подписей, соответствующих подписям общего пользователя android.uid.system». Защитите безопасность системы.

Наконец, атрибут android: sharedUserId может не только помещать apk в системный процесс, но также настраивать несколько APK для работы в одном процессе.

Обмен данными должен быть полезным.

Что такое UID

Как мы все знаем, Pid — это идентификатор процесса, Uid — это идентификатор пользователя, но Android — это не то же самое, что компьютер. У каждого пользователя компьютера есть Uid, который запускает программу, Uid этой программы — это этот пользователь, и каждая программа в Android Существует Uid. По умолчанию Android назначает Uid с разным общим уровнем для каждой программы. Если вы звоните друг другу, только Uid может быть одинаковым. Это обеспечивает определенную степень безопасности общих данных. Данные не могут быть получены произвольно между программами.

Установите UID вашего собственного приложения на UID системного процесса

Существует три типа UID системного процесса:

• android:sharedUserId=»android.uid.system»
• android:sharedUserId=»android.uid.shared»
• android:sharedUserId=»android.media»
  Давайте поэкспериментируем с первым. Две другие реализации будут такими же.

Объявить UID

Во-первых, нам нужно объявить UID приложения в манифесте:

Фирменная упаковка

Предварительным условием для упаковки подписи является наличие файла подписи системы, который обычно находится в каталоге build / target / product / security исходного кода, а пользовательские системы некоторых производителей размещаются в других каталогах. Например, Nanopc3, который я использую, находится в следующем каталоге, который может быть глобальным Найдите его. Сначала я также использовал каталог сборки, но его не удалось установить после упаковки. Позже я обнаружил, что в каталоге vendor также был / (ㄒ o ㄒ) /

загрузка… повторно загрузитьОтмена загрузка… повторно загрузитьОтмена

Среди них android: sharedUserId = «android.uid.system» соответствует двум файлам platform.pk8 и platform.x509.pem.
Вот три распространенных способа импорта системных подписей:

• Повторно подписать сгенерированный apk
• Повторно подписать собственный файл подписи приложения
• Скомпилировать из mk файла

Уже есть apk

Созданный файл apk можно повторно подписать с помощью следующей команды через файл signapk.jar в каталоге исходного кода / out / host / linux-x86 / framework.

java -jar signapk.jar platform.x509.pem platform.pk8 my.apk new.apk

Обратите внимание, что четыре файла signapk.jar, platform.x509.pem, platform.pk8 и my.apk должны находиться по одному и тому же пути при использовании этой инструкции, в противном случае вам нужно изменить путь самостоятельно.

Восстановить подпись

После создания собственного файла ключа используйте инструмент keytool-importkeypair для повторного создания подписи с помощью следующей команды:

keytool-importkeypair -k demo.jks -p 123456 -pk8 platform.pk8 -cert platform.x509.pem -alias demo

• demo.jks: файл подписи
• 123456: пароль файла подписи
• platform.pk8, platform.x509.pem: файл подписи системы
• демо: псевдоним файла подписи

Инструмент keytool-importkeypair можно загрузить сСкачать здесь。

Используйте файл mk для компиляции в исходной среде

Я не тестировал этот метод, потому что плохо разбираюсь в файлах mk. В обычных условиях он не будет использоваться. В конце концов, он в основном разработан с использованием инструментов ide. Достаточно двух вышеуказанных методов. При необходимости добавим позже.

Источник

Основы безопасности операционной системы Android. Уровень ядра

Вступление

Самой распространенной операционной системой для смартфонов на сегодняшний день является Android. Но не только этот факт подогревает интерес к ней. Открытость, возможность что-то настроить, подкрутить, и, естественно, сломать тоже в немалой степени способствуют увеличению популярности этой платформы. Я попробую поделиться опытом, как устроена эта операционная система, а так же рассмотреть систему безопасности. Всем, кому интересно, добро пожаловать! В этой статье я рассмотрю безопасность на уровне ядра.

Disclaimer

Термины я буду стараться писать на английком языке, так как боюсь ошибиться в их переводе. Если кто-то знает, как их красиво перевести на русский язык, напишите мне, и я дам перевод этих терминов. Желательно, чтобы у вас под рукой находились исходный код Android (хотя я и буду стараться давать ссылки на файлы в Интернете), потому что я иногда буду давать ссылки на файлы, где находится та или иная функциональность. Как загрузить исходный код, можно почитать здесь или вот в этой статье на Хабре.

Список статей

Стек Android

Ну никуда не деться от этой картинки. Я нашел её на просторах Интернета и нужна она для того, чтобы понять из чего состоит Android. Итак, в стеке Android выделяют четыре уровня (снизу-вверх):

1. Linux kernel (Ядро Linux)
2. Native Libraries
3. Application Framework
4. Applications (Приложения)

Linux kernel. Как неудивительно это звучит, но изначально, Android Inc. — это стартап. Как и во всех стартапах, в этой компании стояла задача максимально использовать уже существующие решения. Поэтому в качестве ядра этой платформы был выбран Linux из-за его открытости и наличия необходимой функциональности. В Android ядро Linux управляет памятью, процессами, а так же используется в качестве hardware abstraction layer (HAL). Насколько мне известно, в Linux драйвера либо встроены в ядро, либо разработаны в виде загружаемых модулей ядра. Так как в Android загрузка модулей ядра по умолчанию отключена, а если встраивать все драйвера, то ядро очень сильно разрастется, то было принято решение создать промежуточный слой (proxy) между ядром и драйверами, который и назвали HAL. Таким образом, HAL — это просто набор интерфейсов, имплементация которых реализована в драйверах. С другой стороны в ядро были добавлены некоторые системы, которые характерны только для Android систем. На данный момент, они пока не включены в основную ветку ядра Linux, поэтому просто скачать ядро Linux и заменить им ядро Android не получится. Среди них следует выделить, Binder (обеспечивает межпроцессное взаимодействие IPC/RPC), Asynchronous SHared MEMory — Ashmem (драйвер разделяемой памяти), Wakelocks (механизм, который позволяет предотвращать затемнение экрана и/или отключение процессора), Low Memory Killer, Alarm, Logger и т.д.

Native Libraries. К этому слою относятся различные нативные библиотеки, которые необходимы для работы Android. Они так же позаимствованы у open-source сообщества. Среди них мы можем найти SQLite, WebKit и т.д.

Android Framework. К этому слою относится то, с чем мы обычно взаимодействуем, когда пишем наши приложения для Android (PowerManager, ActivityManager, NotificationManager и т.д.).

Applications. Приложения бывают двух типов: те, что поставляются вместе с образом системы (системные) и приложения, которые мы загружаем из маркета или других источников. В первом случае, в устройстве приложения находятся в «/system/app» директории, во втором случае в «/data/app».

Безопасность на уровне ядра

Давайте рассмотрим процесс установки приложения на Android устройство. Существует несколько способов установить приложение на устройство (в общем случае):

1. Используя приложение PackageInstaller
2. Используя приложение Android Market
3. Используя комманду adb install

На рисунке, например, приложение ex1.apk устанавливается с помощью PackageInstaller (используется в случае, если вам, например, по почте прислали приложение и вы хотите его установить с устройства), ex2.apk устанавливается с помощью Android Market (Google Play), и приложение ex3.apk устанавливается с помощью комманды adb install ex3.apk (обычно эта комманда используется разработчиками приложений для установки приложения с компьютера).

Во время установки, Android каждому приложению по умолчанию присваивает уникальные user ID (UID) и group ID (GID), таким образом каждому приложению в этой операционной системе соответсвует свой пользователь. Имя пользователя обычно имеет формат app_x, а идентификаторы пользователя вычисляется по формуле (Process.FIRST_APPLICATION_UID + x), Process.FIRST_APPLICATION_UID равен 10000. Эти идентификаторы приложения не изменяются. Список установленных приложений хранится в файле «/data/system/packages.list» и если у вас рутованый телефон, или вы работаете с эмулятором, то вы можете просмотреть этот файл, используя следующую комманду:

У каждого приложения есть своя домашняя директория, например /data/data/

— имя Android пакета, например com.ex.ex1 Имя Android пакета задается в свойстве package в файле AndroidManifest.xml Эта папка — Internal storage (внутреннее хранилище), директория, где приложение хранит все свои приватные данные, и к которому разработчики приложений получают доступ используя функции Context.getFilesDir() или Context.getDir() У этой папки права доступа определены как drwxr-x—x, т.е. только владелец и пользователи входящие в группу владельцев имеют полный доступ к этой папке. А так как каждое приложение определено как уникальный пользователь, то это означает, что приложения, по умолчанию, не имеют доступа к информации друг друга. Хотя при создании файла во внутреннем хранилище можно явно задать, что этот файл будет MODE_WORLD_READABLE и/или MODE_WORLD_WRITABLE

Кроме того, на уровне ядра уникальные UID и GID каждого приложения используются для разделения доступа к ресурсам системы (память и процессорное время). Таким образом, на уровне ядра для каждого приложения создается своя собственная песочница (Application Sandbox).

С другой стороны, разработчик приложения может указать, что некоторые ЕГО приложения должны иметь один и тот же UID. В AndroidManifest.xml файле для этого есть специальное свойство sharedUserId В этом случае, эти приложения будут иметь доступ к ресурсам друг-друга, но только если они подписаны одним и тем же ключом разработчика.

Некоторые permission (разрешения) так же работают на уровне ядра. Давайте, например, рассмотрим наиболее используемое разрешение android.permission.INTERNET Если приложение запрашивает это разрешение, то Android во время установки дополнительно включает это приложение в специальную группу «inet». Так же работают и некоторые другие разрешения. Список соответствия между этими разрешениями и соответствующими группами можно найти в файле frameworks/base/data/etc/platform.xml:

Список соответствия между именами этих групп и значениями (GID) задан в явном виде в файле system/core/include/private/android_filesystem_config.h в массиве структур android_ids[]:

Таким образом, если приложение пытается подключиться к Интернету, ядро проверяет, находится ли это приложение в группе с идентификатором AID_INET. Если нет, то приложению запрещается доступ. Код этой проверки очень тривиальный:

Заключение

Это моя первая статья на Хабре, так что не судите строго. Если сообществу интересно, то я продолжу в следующих статьях описывать внутренности Android. Я понимаю, что много не знаю, да и времени всегда не хватает, но я постараюсь поделиться тем, что уже пропустил через себя. Надеюсь, что узнаю что-то новое из комментариев! Если кому-то интересна какая-то определенная тема, то пишите в комментариях, постараюсь в будущих статьях учесть ваши пожелания.

Источник