Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Personalizzare SELinux

Dopo aver integrato il livello base della funzionalità SELinux e aver analizzato a fondo i risultati, è possibile aggiungere le proprie impostazioni dei criteri per coprire le personalizzazioni del sistema operativo Android. Queste politiche devono comunque soddisfare i requisiti del programma di compatibilità Android e non devono rimuovere le impostazioni SELinux predefinite.

I produttori non dovrebbero rimuovere la politica SELinux esistente. Altrimenti, rischiano di interrompere l'implementazione SELinux di Android e le applicazioni che governa. Ciò include le applicazioni di terze parti che dovranno probabilmente essere migliorate per essere conformi e operative. Le applicazioni non devono richiedere alcuna modifica per continuare a funzionare su dispositivi abilitati per SELinux.

Quando inizi a personalizzare SELinux, ricordati di:

  • Scrivi la politica SELinux per tutti i nuovi demoni
  • Usa domini predefiniti quando appropriato
  • Assegna un dominio a qualsiasi processo generato come servizio init
  • Acquisire familiarità con le macro prima di scrivere la politica
  • Invia le modifiche alla politica principale ad AOSP

E ricorda di non:

  • Crea una politica incompatibile
  • Consenti personalizzazione dei criteri per l'utente finale
  • Consenti personalizzazioni dei criteri MDM
  • Spaventare gli utenti con violazioni delle norme
  • Aggiungi backdoor

Consulta la sezione Funzionalità di sicurezza del kernel del documento Definizione di compatibilità Android per requisiti specifici.

SELinux utilizza un approccio di whitelist, il che significa che tutti gli accessi devono essere esplicitamente consentiti nella politica per essere concessi. Poiché la politica SELinux predefinita di Android supporta già il progetto Open Source Android, non è necessario modificare le impostazioni SELinux in alcun modo. Se personalizzi le impostazioni di SELinux, fai molta attenzione a non rompere le applicazioni esistenti. Per iniziare:

  1. Usa l' ultimo kernel Android .
  2. Adotta il principio del privilegio minimo .
  3. Indirizza solo le tue aggiunte ad Android. La politica predefinita funziona automaticamente con la base di codice del progetto Open Source Android .
  4. Compartimentalizza i componenti software in moduli che conducono compiti singolari.
  5. Creare politiche SELinux che isolino tali attività da funzioni non correlate.
  6. Mettere le politiche a *.te file (l'estensione per i file di origine politica SELinux) all'interno dei /device/ manufacturer / device-name /sepolicy directory e l'uso BOARD_SEPOLICY variabili da includere nella vostra build.
  7. Rendi i nuovi domini inizialmente permissivi. Questo viene fatto usando una dichiarazione permissiva nel file .te del dominio.
  8. Analizza i risultati e perfeziona le definizioni del tuo dominio.
  9. Rimuovi la dichiarazione permissiva quando non compaiono ulteriori rifiuti nelle build di userdebug.

Dopo aver integrato la modifica della politica SELinux, aggiungere un passaggio al flusso di lavoro di sviluppo per garantire la compatibilità con SELinux in futuro. In un processo di sviluppo software ideale, la politica SELinux cambia solo quando cambia il modello software e non l'implementazione effettiva.

Quando inizi a personalizzare SELinux, controlla innanzitutto le tue aggiunte ad Android. Se hai aggiunto un componente che svolge una nuova funzione, assicurati che il componente soddisfi la politica di sicurezza di Android, nonché qualsiasi politica associata elaborata dall'OEM, prima di attivare la modalità di applicazione.

Per evitare problemi inutili, è meglio essere sovraccarichi e sovracompatibili piuttosto che troppo restrittivi e incompatibili, il che si traduce in funzioni del dispositivo rotte. Al contrario, se le tue modifiche andranno a beneficio degli altri, dovresti sottoporre le modifiche alla politica SELinux predefinita come patch . Se la patch viene applicata ai criteri di sicurezza predefiniti, non sarà necessario apportare questa modifica ad ogni nuova versione di Android.

Esempi di dichiarazioni di politica

SELinux si basa sul linguaggio del computer M4 e quindi supporta una varietà di macro per risparmiare tempo.

Nel seguente esempio, a tutti i domini viene concesso l'accesso per leggere o scrivere su /dev/null e leggere da /dev/zero .

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Questa stessa affermazione può essere scritta con le macro SELinux *_file_perms (stenografia):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Esempio di politica

Ecco una politica di esempio completa per DHCP, che esamineremo di seguito:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Analizziamo l'esempio:

Nella prima riga, la dichiarazione del tipo, il daemon DHCP eredita dalla politica di sicurezza di base ( domain ). Dagli esempi di istruzioni precedenti, DHCP può leggere e scrivere su /dev/null .

Nella seconda riga, DHCP è identificato come dominio consentito.

Nella init_daemon_domain(dhcp) , i criteri init_daemon_domain(dhcp) DHCP è generato da init e può comunicare con esso.

Nella net_domain(dhcp) , il criterio consente a DHCP di utilizzare funzionalità di rete comuni dal dominio di net , come la lettura e la scrittura di pacchetti TCP, la comunicazione tramite socket e l'esecuzione di richieste DNS.

Nella riga allow dhcp proc_net:file write; , la politica afferma che DHCP può scrivere su file specifici in /proc . Questa riga mostra l'etichettatura dei file di SELinux a grana fine. Utilizza l'etichetta proc_net per limitare l'accesso in scrittura solo ai file in /proc/sys/net .

Il blocco finale dell'esempio che inizia con allow dhcp netd:fd use; illustra come le applicazioni possono interagire tra loro. La politica afferma che DHCP e netd possono comunicare tra loro tramite descrittori di file, file FIFO, socket di datagramma e socket di flusso UNIX. DHCP può solo leggere e scrivere dai socket di datagramma e stream UNIX e non crearli o aprirli.

Controlli disponibili

Classe Autorizzazione
file
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
elenco
add_name remove_name reparent search rmdir open audit_access execmod
presa di corrente
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
filesystem
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
processi
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
sicurezza
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
capacità
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

DI PIÙ

E ALTRO

non consentire mai regole

SELinux non neverallow regole che vietano comportamenti che non dovrebbero mai verificarsi. Con i test di compatibilità , SELinux non neverallow regole su tutti i dispositivi.

Le seguenti linee guida hanno lo scopo di aiutare i produttori a evitare errori relativi a non neverallow regole durante la personalizzazione. I numeri delle regole qui utilizzati corrispondono ad Android 5.1 e sono soggetti a modifiche in base al rilascio.

Regola 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Vedi la pagina man per ptrace . La funzionalità sys_ptrace garantisce la possibilità di ptrace qualsiasi processo, il che consente un grande controllo su altri processi e dovrebbe appartenere solo ai componenti di sistema designati, descritti nella regola. La necessità di questa capacità indica spesso la presenza di qualcosa che non è pensato per build o funzionalità rivolte all'utente che non sono necessarie. Rimuovere il componente non necessario.

Regola 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Questa regola ha lo scopo di impedire l'esecuzione di codice arbitrario sul sistema. In particolare, afferma che viene eseguito solo il codice su /system , il che consente garanzie di sicurezza grazie a meccanismi come l'avvio verificato. Spesso, la soluzione migliore quando si verifica un problema con questa regola di non neverallow è di spostare il codice offensivo nella partizione /system .

Personalizzare SEPolicy in Android 8.0+

Questa sezione fornisce linee guida per la politica SELinux del fornitore in Android 8.0 e versioni successive, inclusi i dettagli sulle estensioni SEPolicy e SEPolicy di Android Open Source Project (AOSP). Per ulteriori informazioni su come la politica SELinux è mantenuta compatibile tra le partizioni e le versioni di Android, vedere Compatibilità .

Inserimento delle politiche

In Android 7.0 e BOARD_SEPOLICY_DIRS precedenti, i produttori di dispositivi potevano aggiungere criteri a BOARD_SEPOLICY_DIRS , inclusi criteri intesi ad aumentare i criteri AOSP su diversi tipi di dispositivi. In Android 8.0 e versioni successive, l'aggiunta di una politica a BOARD_SEPOLICY_DIRS inserisce la politica solo nell'immagine del fornitore.

In Android 8.0 e versioni successive, esiste un criterio nelle seguenti posizioni in AOSP:

  • sistema / sepolicy / pubblico . Include la politica esportata per l'uso nella politica specifica del fornitore. Tutto va nell'infrastruttura di compatibilità di Android 8.0. La politica pubblica è destinata a persistere tra le versioni in modo da poter includere qualsiasi cosa /public nella politica personalizzata. Per questo motivo, il tipo di politica che può essere inserito in /public è più limitato. Considera questa API della politica esportata dalla piattaforma: tutto ciò che riguarda l'interfaccia tra /system e /vendor appartiene qui.
  • sistema / sepolicy / privato . Include la politica necessaria per il funzionamento dell'immagine di sistema, ma di quale politica dell'immagine del fornitore non dovrebbe avere conoscenza.
  • system / sepolicy / vendor . Include i criteri per i componenti che entrano in /vendor ma esistono nella struttura della piattaforma principale (non nelle directory specifiche del dispositivo). Questo è un artefatto della distinzione del sistema di costruzione tra dispositivi e componenti globali; concettualmente questa è una parte della politica specifica del dispositivo descritta di seguito.
  • dispositivo / manufacturer / device-name / sepolicy . Include criteri specifici del dispositivo. Include anche personalizzazioni del dispositivo in base al criterio, che in Android 8.0 e versioni successive corrisponde al criterio per i componenti sull'immagine del fornitore.

Scenari di politica supportati

Sui dispositivi che si avviano con Android 8.0 e versioni successive, l'immagine del fornitore deve funzionare con l'immagine di sistema OEM e l'immagine di sistema AOSP di riferimento fornita da Google (e passare CTS su questa immagine di riferimento). Questi requisiti assicurano una netta separazione tra il framework e il codice del fornitore. Tali dispositivi supportano i seguenti scenari.

estensioni di sole immagini del fornitore

Esempio : aggiunta di un nuovo servizio a vndservicemanager del fornitore che supporta i processi dall'immagine del fornitore.

Come per i dispositivi che si avviano con le versioni precedenti di Android, aggiungi la personalizzazione specifica del device/ manufacturer / device-name /sepolicy in device/ manufacturer / device-name /sepolicy . Le nuove politiche che regolano il modo in cui i componenti del fornitore interagiscono con (solo) altri componenti del fornitore dovrebbero coinvolgere i tipi presenti solo nel device/ manufacturer / device-name /sepolicy . La politica scritta qui consente al codice sul fornitore di funzionare, non verrà aggiornato come parte di un OTA solo per il framework e sarà presente nella politica combinata su un dispositivo con l'immagine del sistema AOSP di riferimento.

supporto immagine fornitore per lavorare con AOSP

Esempio : aggiunta di un nuovo processo (registrato con hwservicemanager del fornitore) che implementa un HAL definito da AOSP.

Come per i dispositivi che si avviano con le versioni precedenti di Android, esegui personalizzazioni specifiche del device/ manufacturer / device-name /sepolicy in device/ manufacturer / device-name /sepolicy . La politica esportata come parte del system/sepolicy/public/ è disponibile per l'uso e viene spedita come parte della politica del fornitore. I tipi e gli attributi della politica pubblica possono essere utilizzati nelle nuove regole che dettano le interazioni con i nuovi bit specifici del fornitore, fatte neverallow restrizioni neverallow previste. Come nel caso del solo fornitore, la nuova politica qui non verrà aggiornata come parte di un OTA solo per il framework e sarà presente nella politica combinata su un dispositivo con l'immagine del sistema AOSP di riferimento.

estensioni di sola immagine di sistema

Esempio : aggiunta di un nuovo servizio (registrato con un gestore di servizi) a cui si accede solo da altri processi dall'immagine di sistema.

Aggiungi questo criterio a system/sepolicy/private . È possibile aggiungere ulteriori processi o oggetti per abilitare la funzionalità nell'immagine di sistema del partner, a condizione che questi nuovi bit non debbano interagire con nuovi componenti sull'immagine del fornitore (in particolare, tali processi o oggetti devono funzionare completamente senza politica dall'immagine del fornitore) . La politica esportata da system/sepolicy/public è disponibile qui così come per le estensioni di sole immagini del fornitore. Questa politica fa parte dell'immagine di sistema e potrebbe essere aggiornata in un OTA solo framework, ma non sarà presente quando si utilizza l'immagine di sistema AOSP di riferimento.

estensioni immagine fornitore che servono componenti AOSP estesi

Esempio: un nuovo HAL non AOSP per l'uso da parte di client estesi che esiste anche nell'immagine di sistema AOSP (come un server_sistema esteso).

La politica di interazione tra sistema e fornitore deve essere inclusa nella directory device/ manufacturer / device-name /sepolicy spedita nella partizione fornitore. Questo è simile allo scenario sopra riportato per l'aggiunta del supporto dell'immagine fornitore per funzionare con l'immagine AOSP di riferimento, tranne per il fatto che i componenti AOSP modificati potrebbero anche richiedere criteri aggiuntivi per funzionare correttamente con il resto della partizione di sistema (che va bene finché avere le etichette pubbliche di tipo AOSP).

La politica di interazione dei componenti AOSP pubblici con estensioni di sola immagine di sistema dovrebbe essere in system/sepolicy/private .

estensioni immagine di sistema che accedono solo alle interfacce AOSP

Esempio: un nuovo processo di sistema non AOSP deve accedere a un HAL su cui si basa AOSP.

Questo è simile all'esempio di estensione di sola immagine di sistema , ad eccezione dei nuovi componenti di sistema che possono interagire attraverso l'interfaccia di system/vendor . La politica per il nuovo componente di sistema deve andare in system/sepolicy/private , il che è accettabile a condizione che sia attraverso un'interfaccia già stabilita da AOSP in system/sepolicy/public (cioè ci sono i tipi e gli attributi richiesti per la funzionalità). Sebbene la politica possa essere inclusa nella politica specifica del dispositivo, non sarebbe in grado di utilizzare altri tipi di system/sepolicy/private o modificare (in alcun modo che influisce sulla politica) a seguito di un aggiornamento solo del framework. Il criterio può essere modificato in un OTA solo framework, ma non sarà presente quando si utilizza un'immagine di sistema AOSP (che non avrà neanche il nuovo componente di sistema).

estensioni immagine fornitore che servono nuovi componenti di sistema

Esempio: aggiunta di un nuovo HAL non AOSP per l'utilizzo da parte di un processo client senza un analogo AOSP (e quindi richiede un proprio dominio).

Analogamente all'esempio delle estensioni AOSP , la politica per le interazioni tra sistema e fornitore deve andare nella directory device/ manufacturer / device-name /sepolicy spedita sulla partizione fornitore (per garantire che la politica di sistema non sia a conoscenza di dettagli specifici del fornitore). È possibile aggiungere nuovi tipi pubblici che estendono la politica in system/sepolicy/public ; ciò dovrebbe essere fatto solo in aggiunta alla politica AOSP esistente, ovvero non rimuovere la politica pubblica AOSP. I nuovi tipi pubblici possono quindi essere utilizzati per la politica in system/sepolicy/private e in device/ manufacturer / device-name /sepolicy .

Tieni presente che ogni aggiunta a system/sepolicy/public aggiunge complessità esponendo una nuova garanzia di compatibilità che deve essere tracciata in un file di mappatura e che è soggetta ad altre restrizioni. Solo i nuovi tipi e le corrispondenti regole di autorizzazione possono essere aggiunti in system/sepolicy/public ; gli attributi e le altre dichiarazioni di politica non sono supportati. Inoltre, non è possibile utilizzare nuovi tipi pubblici per etichettare direttamente gli oggetti nella politica /vendor .

Scenari di politica non supportati

I dispositivi che si avviano con Android 8.0 e versioni successive non supportano il seguente scenario ed esempi di criteri.

Estensioni aggiuntive all'immagine di sistema che richiedono l'autorizzazione per i nuovi componenti dell'immagine del fornitore dopo un OTA solo per il framework

Esempio: un nuovo processo di sistema non AOSP, che richiede un proprio dominio, viene aggiunto nella prossima versione di Android e deve accedere a un nuovo HAL non AOSP.

Simile al nuovo sistema (non AOSP) e all'interazione dei componenti del fornitore , tranne il nuovo tipo di sistema è introdotto in un OTA solo per il framework. Sebbene il nuovo tipo possa essere aggiunto alla politica in system/sepolicy/public , la politica del fornitore esistente non è a conoscenza del nuovo tipo in quanto sta monitorando solo la politica pubblica del sistema Android 8.0. AOSP gestisce ciò esponendo le risorse fornite dal fornitore tramite un attributo (ad esempio hal_foo attributo hal_foo ) ma poiché le estensioni dei partner di attributo non sono supportate in system/sepolicy/public , questo metodo non è disponibile per la politica del fornitore. L'accesso deve essere fornito da un tipo pubblico precedentemente esistente.

Esempio: una modifica a un processo di sistema (AOSP o non AOSP) deve cambiare il modo in cui interagisce con il nuovo componente del fornitore non AOSP.

La politica sull'immagine di sistema deve essere scritta senza conoscere specifiche personalizzazioni del fornitore. La politica relativa a interfacce specifiche in AOSP è quindi esposta tramite attributi in system / sepolicy / public in modo che la politica del fornitore possa optare per la futura politica di sistema che utilizza questi attributi. Tuttavia, le estensioni degli attributi in system/sepolicy/public non sono supportate , quindi tutti i criteri che determinano il modo in cui i componenti di sistema interagiscono con i nuovi componenti del fornitore (e che non sono gestiti da attributi già presenti nel system/sepolicy/public AOSP system/sepolicy/public ) devono essere nel device/ manufacturer / device-name /sepolicy . Ciò significa che i tipi di sistema non possono modificare l'accesso consentito ai tipi di fornitori come parte di un OTA solo framework.