Dove sono archiviate le informazioni sull'ID utente / gruppo su Android e come posso interpretarle?


15

Mi chiedo da un po 'di tempo ormai; dove Android memorizza le informazioni sull'ID utente e del gruppo?

Ad esempio, su Linux standard, le informazioni su utenti e gruppi sono memorizzate in /etc/passwde /etc/group, rispettivamente. Quando aggiungi un utente a un gruppo, il suo nome utente / uid viene aggiunto all'elenco degli utenti di quel gruppo, ad esempio la voce del mio gruppo audio in /etc/groupappare così:

audio:x:29:pulse,edge-case

Dove impulso viene mappato sull'UID del demone pulseaudio e edge-case viene mappato sul mio UID (1000), sulla mia scatola di Linux.

A quanto ho capito, ogni app che viene installata su Android ottiene il proprio IDI e gid e questa è la base del "sandboxing" delle app che si verifica su Android mentre vengono eseguite tutte nel proprio processo e non possono accedere ai dati di un'altra processo o file di proprietà di un'altra app a meno che non ci siano dichiarazioni in un file manifest creato da programmatori di app che detta quali informazioni devono essere condivise con altre app e quali no. Questo è anche il modo in cui le app ottengono o piuttosto richiedono l'accesso ai servizi di rete durante l'installazione chiedendo di essere aggiunte al gruppo INTERNET o qualcosa del genere, non citarmi sul nome del gruppo di rete NET, potrebbe essere più simile a INET o INET6, in ogni caso so che esistono diversi livelli di accesso alla rete che possono essere concessi a un'applicazione tramite questo meccanismo su Android.

La mia domanda è: dove sono archiviate queste informazioni in Android?

Inoltre, è possibile modificare?

Vorrei integrare uno stack glibc con esso e i dati al suo interno nei miei /etc/{passwd,group}file, fidati di me, esistono sul mio telefono, ho persino installato molti altri goodies.

Aggiornamento: ho fatto più ricerche e questo potrebbe essere quello che sto cercando.

Dovrò scavare un po 'più a fondo e assicurarmi che sia tutto ciò che sto cercando.

Aggiornamento: (5:40 27 giugno 2014)

Dal momento che qualcuno pensa che non sappia cosa sto facendo o di cui parlo, vorrei chiarire;

Gli UID utente su Android sono sfalsati con 100000 e gli UID app vengono sfalsati con 10000 quando mappati al numero utente _ numero app, quindi quando un ps mostra qualcosa come u0_a10 che significa che l'utente con UID 100000 esegue app con UID 10010,

Ho estratto i nomi UID e user / daemon da system / core / include / private / android_filesystem_config.h e li ho usati per aggiornare i miei file / etc / passwd e / etc / group (sulla mia casella Android), ad esempio mio / etc / Il file passwd (sulla mia casella Android) è simile al seguente:

....
brainard:x:100002:100002:Professor Brainard,0420,,:/home/brainard
:/bin/bash
radio:x:1001:1001::/data/radio:/bin/false
bluetooth:x:1002:1002::/data/bluetooth:/bin/false
graphics:x:1003:1003::/home/graphics:/bin/false
input:x:1004:1004::/home/input:/bin/false
camera:x:1006:1006::/home/camera:/bin/false
log:x:1007:1007::/home/log:/bin/false
compass:x:1008:1008::/home/compass:/bin/false
mount:x:1009:1009::/home/mount:/bin/false
wifi:x:1010:1010::/home/wifi:/bin/false
adb:x:1011:1011::/home/adb:/bin/false
install:x:1012:1012::/home/install:/bin/false
media:x:1013:1013::/home/media:/bin/false
dhcp:x:1014:1014::/home/dhcp:/bin/false
....

Ho impostato la configurazione in /etc/adduser.conf per creare nuovi utenti in questo modo (sulla mia casella Android):

# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
# allocated user accounts/groups.
FIRST_UID=100001
LAST_UID=199999

FIRST_GID=100001
LAST_GID=199999

Ciò è conforme alla politica di Android, ho lasciato che gli utenti di sistema "basati su glibc" fossero ancora creati nell'intervallo 100-999, credo e ho modificato l'utente audio sui miei file / etc / passwd e / etc / group su 1005, come è su Android.

Devo aggiornare Android e sincronizzarlo con le informazioni relative ai miei UID utente e con i miei demoni o UID utente di sistema dallo stack glibc.

Puoi leggere di più su questo nel libro "Embedded Android" di Karim Yaghmour Venduto qui

Il mio obiettivo è far funzionare programmi come NVIDC, ma ho bisogno di sincronizzare UID e GID in modo che Android sia a conoscenza dei miei utenti e dei gruppi a cui appartengono in modo che, ad esempio, il mio utente di brainard abbia accesso ai dispositivi audio.

Inoltre, devo informare Android di Postres e della sua appartenenza al gruppo della rete in modo che possa aprire socket e consentire l'accesso ai database. Per il momento ho disabilitato PARANOID_NETWORKING nel kernel, ma questo hack serve solo a rendere Android sicuro come Vanilla Linux, nientemeno. Sarebbe bello mantenere l'impostazione paranoica e applicare le autorizzazioni di gruppo a ciò che i demoni / utenti ritengo opportuno.

Ciò renderebbe Android un ottimo sistema operativo per server pubblici con tali controlli paranoici e ottimizzati. Immagina di avere accesso a Kerberos, LDAP, PAM o Quando usi il tuo telefono come WAP con Radius configurato, tutti disponibili da Debian e altri repository di distribuzione gratuiti.

Ho capito tutto, ho solo bisogno di sapere come aggiornare il database UID / GID di Android, che viene aggiornato ogni volta che installi un'app, quindi so che è possibile.

Aggiornamento: (19:08 30 giugno 2014)

Dopo aver esaminato i dati nei seguenti file ...

/data/system/packages.list
/data/system/packages.xml
/data/system/user/userlist.xml
/data/system/user/0.xml

... Ho aggiornato la mia domanda per includere "come posso interpretarlo?"

  • Penso che dovrò creare un modulo PAM personalizzato e fondere Bionic e Glibc in una singola libreria C, devono essere compatibili con le applicazioni su entrambi i lati, senza eccezioni, aspettarsi eccezioni C ++ che siano; p --- ho scritto un paio di regole pollice-2 :) per me stesso da seguire. Potrei anche aver bisogno di scrivere un wrapper per i più diffusi sistemi di gestione dei pacchetti come rpm e apt che falsi un'installazione apk e dia a ogni nuovo pacchetto deb | rpm un UID e forse semplicemente colleghi tutto in FHS. Questa potrebbe essere la soluzione ideale per cui potrei cercare, anche se la maggior parte del lavoro, dato che ognuno avrebbe bisogno di una serie di autorizzazioni nel proprio "manifest", forse un menu durante l'installazione che un utente può dare e prendere secondo necessità.
  • Qualcuno ha un buon riferimento che spiega la sintassi di questi file? Non sono molto esperto di XML, per non parlare del fatto che l'uso di solito dipende dall'applicazione che lo interpreta.
  • Capisco il packages.listfile ad eccezione della nullvoce nell'ultima colonna, qualcuno può spiegarlo?

Risposte:


1

Visto il GET_ACCOUNTSpermesso? ( Nota ed.: Quella particolare funzione potrebbe non essere altrettanto utile per questa domanda, poiché è apparentemente una funzionalità sviluppata per l'autenticazione web.)

Personalmente, sto leggendo l'argomento per quanto riguarda i valori UID / GID calcolati al momento dell'installazione di APK - attualmente, come ricerca di un semplice articolo di blog - ma vorrei studiare questo argomento un po 'di più. Facendo riferimento alla documentazione di riferimento su queste funzionalità del sistema operativo collegate in modo multiplo, in Android sembra che ci sia un servizio account nel sistema operativo Android. ( Ed. Nota Può sembrare, inoltre, che il Servizio Account in Android potrebbe essere più un servizio sviluppato per l'applicazione relativa agli account Web di un utente Android)

Anche se personalmente sono preoccupato di scrivere un altro articolo, immediatamente, ma sicuramente il Servizio Account potrebbe richiedere ulteriori studi. Forse potrebbe essere rilevante, ortogonalmente, per quanto riguarda l'applicazione di Kerberos su dispositivi Android. Esistono alcuni lavori esistenti per quanto riguarda l'implementazione dei servizi Kerberos sulla piattaforma Android. Per le app Web, ovviamente c'è OAuth / OAuth2.

Evidentemente, Android non utilizza i file passwd / shadow UNIX convenzionali ( Anderson2013 ). La mia migliore stima, al momento, è che il servizio di account del sistema operativo Android potrebbe essere un argomento per un modo di un ulteriore studio ... almeno, fino a scoprire che il servizio di account Android potrebbe essere piuttosto un'utilità di autenticazione web ( API: AccountManager ).

Sono sicuro che c'è qualcosa in più sull'alternativa di Android /etc/passwd, da qualche parte nel codice sorgente di Android. Speriamo che sia vicino, tuttavia la stessa cosa potrebbe essere affrontata in CyanogenMod.


1

Ecco i miei pensieri su come Android implementa la ricerca UID / GID. Spero che possa essere utile a chiunque abbia delle domande.

grp_pwd.cpp descrive come Android traduce un UID / nome utente in una passwdstruttura. Dalla getpwuidfunzione possiamo vederlo

  1. L'UID viene prima confrontato agli aiuti predefiniti da generated_android_ids.hsotto $(AOSP_ROOT)/out/soong/.intermediates/bionic/libc/generated_android_ids/gen, che viene generata da android_filesystem_config.h secondo bionico / libc / Android.bp e bionico / Android.bp . Gli AID sono memorizzati in un nome utente nella mappa UID in struct android_id_info android_ids[]e quando vengono cercati, vengono convertiti nella passwdstruttura con uide gidimpostati su AID, home directory impostata su /e shell impostata su /system/bin/sh( codice ).

  2. Se non viene trovato alcun utente nel passaggio precedente, la funzione cercherà gli utenti definiti dall'OEM. Gli UID di questi utenti vanno da AID_OEM_RESERVED_STARTa AID_OEM_RESERVED_ENDe AID_OEM_RESERVED_2_STARTa AID_OEM_RESERVED_2_END. Gli utenti definiti dal fornitore vengono archiviati in /vendor/etc/passwd. I nomi utente sono impostati su oem_${uid}e gli altri attributi sono impostati allo stesso modo degli utenti AID.

  3. Infine, controllerà tutti gli utenti dell'app app_id_to_passwd()e il processo sarà molto simile.

Se desideri ottenere tutte le passwdvoci, dai un'occhiata allo getpwent()stesso file e anche alla manpage di getpwent (3)


0

Innanzitutto, poiché si è consapevoli del fatto che ogni applicazione ha il proprio PID (ID processo) univoco, questo PID è assegnato all'applicazione dal kernel del sistema operativo.

  1. In Android ADT puoi ovviamente visualizzare il PID nel logcat.
  2. Se si desidera visualizzare il PID sul dispositivo, è necessario installare un'applicazione dal Play Store (non è possibile garantire che il PID visualizzato dall'app sia autentico o meno)
  3. Venire alla parte di modifica è un grande no.
  4. No, non è possibile modificare il PID come desiderato poiché ciò comporterebbe problemi di sicurezza e l'ambiguità tra le app per un'altra app potrebbe avere lo stesso PID, risultando in conflitto.

6
Questo non ha nulla a che fare con PID, che è variabile ad eccezione di init che è sempre PID 1 perché è il primo processo da creare, questo ha più a che fare con la sensibilizzazione di Android agli UID dal mio stack glibc (e viceversa ), come il demone Postgres, e no, non è un problema di sicurezza, rendere lo stack Bionic consapevole di questi UID e GID extra che ho sul mio sistema aumenterebbe la sicurezza. In che modo rendere consapevoli Android Kerberos, LDAP e PAM può essere un difetto di sicurezza ?! Sarebbe meraviglioso!
Overloaded_Operator il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.