Esistono dispositivi Google che supportano le funzionalità nel loro kernel predefinito?

Se avessi root senza sistema (nessuna modifica fatta per /systempartizionare) un dispositivo Nexus, sarei in grado di impostare le capacità sugli eseguibili senza cambiare il binario del kernel originale?

Spesso voglio gestire i file senza restrizioni dal mio terminale (richiesto CAP_DAC_READ_SEARCH) . Tuttavia, voglio anche non usare il superutente.
Le cose richieste sono strumenti per impostare i limiti sul supporto del kernel per usarli (non si basa su altre cose dello spazio utente) .

Il problema è che non possiedo tale dispositivo. Quindi non posso dire se funzionerebbe su nessuno dei Nexus 5X Nexus 6P Nexus 9 Pixel C.

— user2284570
fonte

Inoltre, non sono stato in grado di trovare un emulatore nexus ...

— user2284570,

Ne dubito ... Poiché Android utilizza Bionic libc e non la libreria GNU libc (glibc) standard, non è nemmeno vicino a POSIX compatibile. Potresti essere in grado di compilare il tuo kernel con un diverso libc come CrystaX NDK invece di Bionic, ma non so nemmeno se ci siano quelle caratteristiche.

— acejavelin,

@acejavelin: la parte userland è richiesta solo per impostare attributi estesi contenenti capacità. Tutto il resto è lato kernel. Ho appena notato che il /system/bin/pingcomando non è impostato sul mio vero dispositivo Samsung, suggerendo CAP_NET_RAW. Tuttavia, non eseguirò il root di un dispositivo reale e non so quale strumento posso usare per vedere le informazioni rilevanti, quindi non posso controllare.

— user2284570,

Perché non eseguire il root di un dispositivo Nexus? È previsto per questo e non annulla la garanzia. È molto semplice ripristinare qualsiasi dispositivo Nexus al suo stato predefinito, non rootato e bloccato, il dispositivo è sostanzialmente non mattoni.

— acejavelin,

@acejavelin: non possiedo un dispositivo nexus ... Il mio obiettivo è la ricerca sulla sicurezza e Google premia solo per i suoi dispositivi. Quindi ho bisogno di sapere se il kernel di uno dei dispositivi nella mia domanda supporta l'utilizzo delle funzionalità xattr. Quello che vedo nella mia scheda galassia è probabilmente legato solo a Samsung. Se non includo il rooting nella mia domanda, potrebbe essere chiuso come poco chiaro .

— user2284570,

Sebbene la domanda sia vecchia, continua ad apparire in cima alle domande senza risposta (i miei tag) . Quindi penso che dovrei rispondere a questo :)

IL SUPPORTO DI AOSP PER LE CAPACITÀ:

La domanda riguarda in particolare i dispositivi Google, non ho mai usato un dispositivo Google. Tuttavia, ciò che posso dire con certezza è che le funzionalità di Linux (processo) devono essere state abilitate sulla maggior parte dei dispositivi (se non tutti) in esecuzione su Android 1.6. Il riferimento si trova in inite system_server, entrambi i componenti primari di AOSP. In Android 4.2, ad esempio, installd- un altro componente principale - è stato realizzato per funzionare con funzionalità scartate.

Le funzionalità del filesystem sono state uno dei principali miglioramenti della sicurezza in Android 4.3 che ha rimosso set-uid/ set-gidda file binari come run-as, impostando le funzionalità dei file su di essi. Ciò ha causato cambiamenti rivoluzionari nel percorso di rooting di Android.

Il supporto per le funzionalità Ambient è stato aggiunto in Android 8 che scoraggia l'uso delle funzionalità dei file:

Le funzionalità dei file, a loro volta, presentano un rischio per la sicurezza poiché qualsiasi processo che esegue un file con funzionalità di file sarà in grado di ottenere tali funzionalità.

Molti initservizi dipendono da essi storaged, ad esempio , compresi i miei sshde i miei dnscrypt-proxyservizi.

SUPPORTO DEL KERNEL PER LE CAPACITÀ:

Venendo alla parte del kernel, la compilazione del kernel senza funzionalità non è facoltativa:

Dal kernel 2.5.27 al kernel 2.6.26, le funzionalità erano un componente del kernel opzionale e potevano essere abilitate / disabilitate tramite l' opzione di configurazione del kernel CONFIG_SECURITY_CAPABILITIES .

Nei kernel precedenti a Linux 2.6.33, le funzionalità dei file erano una funzione opzionale configurabile tramite l' opzione CONFIG_SECURITY_FILE_CAPABILITIES . Da Linux 2.6.33, l'opzione di configurazione è stata rimossa e le capacità dei file fanno sempre parte del kernel.

La versione più vecchia del kernel comune nei repository Android è 2.6.39 che include anche il supporto per le funzionalità dei file.

Il supporto per le capacità del filesystem sul lato kernel deve essere stato ritardato da alcuni OEM, ma hanno dovuto cambiare, perché altrimenti le funzionalità non funzionerebbero. Ad esempio surfaceflinger( compositore di superfici Android ) non funzionerà senza funzionalità di file da Android 7.1.

Il kernel 4.3 di Mainline Linux è stato patchato in settembre 15 per le funzionalità Ambient (di processo), trasferito nel kernel Android 3.18 e 4.1 nel 2016. Quindi fanno necessariamente parte del kernel.

CONCLUSIONE:

Nelle distribuzioni Linux, pochissimi programmi fanno uso delle funzionalità di Linux. Anche se non v'è pam_cap, in gran parte (o tutti?) Distribuzioni usano ancora set-uidsu su, sudo, ping, mount, passwde così via. Ma su Android le funzionalità sono profondamente integrate nel framework e nei servizi di base. La loro rimozione richiederebbe la modifica di centinaia o potrebbe essere migliaia di righe in AOSP e sorgente del kernel. Non ha senso che un OEM (in particolare Google, che ha sviluppato AOSP e modificata del kernel di Linux per Android) non fa uso di questo free-of-costo funzione di sicurezza quando è prontamente disponibile in Android kernel. È una pura funzionalità relativa al sistema operativo, non richiede alcun supporto hardware aggiuntivo. Pertanto, qualsiasi telefono di qualsiasi produttore deve avere funzionalità supportate.

DOMANDE:

sarei in grado di impostare le capacità sugli eseguibili senza modificare il binario del kernel originale?

Sì, devi esserlo.

Le cose richieste sono strumenti per impostare i limiti ...

Sono stato con capsh, getcap, setcap, getpcapsda libcape netcap, pscapda libcap-ngsenza problemi. Ma preferisco le capacità Ambient, quelle sono facili da configurare e non dipendono da alcuna funzionalità del filesystem come Attributi estesi come nel caso delle capacità dei file. È inoltre possibile utilizzare listxattr, getxattr, setxattre removexattrgli strumenti da xattr_syscall_wrappermanipolare security.capabilityo qualsiasi altro XATTR direttamente.

Dal tuo commento:

Ho appena notato che il /system/bin/pingcomando non è setuidsul mio vero dispositivo Samsung, suggerendoCAP_NET_RAW

Il ping di Android non ha set-uidné CAP_NET_RAW. Crea uno speciale socket non RAW IPPROTO_ICMP che - a differenza IPPROTO_RAW- non richiede alcun privilegio.

ULTERIORI RIFERIMENTI:

Oltre ai riferimenti 10+ sopra riportati, ecco alcune altre parti del codice AOSP che supportano e fanno uso delle funzionalità di Linux:

I componenti principali: Bionic libc, init, trusty(OS)
Componenti esterni: libcap ,libcap-ng
Demoni / servizi: zygote (applicazioni biforcuta e system_server), hostapd, wpa_supplicant, dnsmasq, logd, netd( NetLinkmanager, DNS privato), debuggerd(test), sdcarddaemon, performanced, incidentd, mtpd, traced_probes(perfetto), racoon(IPSec), wificondun certo numero di demoni HAL compreso rild.
Eseguibili: reboot (init), dumpstate, tcpdump, strace, iputils( ping, tracerouteecc)
Minijail: uno strumento e una libreria sandbox dedicati dedicati alle funzionalità. adbdfa uso di questa libreria per eliminare i privilegi.
SELinux usa la capabilityclasse per concedere / negare le capacità ai domini.

Conclude che Android dipende fortemente dalle funzionalità di Linux, non è una funzionalità poco utilizzata .

RELAZIONATO:

— Irfan Latif
fonte

Non risponde a nulla. Tutto quello che hai dichiarato è noto. Il punto della domanda è dal momento che è poco utilizzato se i dispositivi con marchio Google lo includono.

— user2284570