Personalizzazione di SELinux

Dopo aver integrato il livello base della funzionalità SELinux e analizzati in modo approfondito i risultati, puoi aggiungere impostazioni delle norme personalizzate per le tue personalizzazioni per il sistema operativo Android. Queste norme devono comunque Rispettare il Programma di compatibilità Android. e non devono rimuovere le impostazioni predefinite di SELinux.

I produttori non devono rimuovere il criterio SELinux esistente. Altrimenti, rischiano di interrompere l'implementazione di Android SELinux e le sue disciplinare. Sono incluse le applicazioni di terze parti che probabilmente dovranno essere per renderli conformi e operativi. Le domande di partecipazione non devono richiedere per continuare a funzionare sui dispositivi abilitati per SELinux.

Quando inizi a personalizzare SELinux, ricordati di:

  • Scrivi criterio SELinux per tutti i nuovi daemon
  • Utilizza i domini predefiniti ove appropriato
  • Assegna un dominio a qualsiasi processo generato come servizio init
  • Acquisisci familiarità con le macro prima di scrivere i criteri
  • Invia le modifiche al criterio principale ad AOSP

Ricorda di non:

  • Crea criterio incompatibile
  • Consenti la personalizzazione dei criteri relativi agli utenti finali
  • Consenti personalizzazioni dei criteri MDM
  • Spaventare gli utenti con violazioni delle norme
  • Aggiungi backdoor

Consulta la sezione Funzionalità di sicurezza del kernel dell' Android documento di definizione della compatibilità per requisiti specifici.

SELinux utilizza un approccio con whitelist, il che significa che tutti gli accessi devono essere consentito nel criterio. Poiché la piattaforma SELinux predefinita di Android supporta già Android Open Source Project, non è necessario modificare le impostazioni SELinux in alcun modo. Se personalizzi le impostazioni di SELinux, fare molta attenzione a non danneggiare le applicazioni esistenti. Per iniziare:

  1. Utilizza la Android più recente del kernel.
  2. Adotta principio del privilegio minimo.
  3. Gestisci solo le tue aggiunte ad Android. Il criterio predefinito funziona con l'API di Android Open Source il codebase del progetto automaticamente.
  4. Compartimentare i componenti software in moduli che conducono attività di machine learning.
  5. Creare criteri SELinux che isolano queste attività da attività non correlate funzioni.
  6. Inserisci questi criteri in file *.te (l'estensione per SELinux file di origine dei criteri) all'interno /device/manufacturer/device-name/sepolicy e usa le variabili BOARD_SEPOLICY per includerle la tua build.
  7. All'inizio, imposta i nuovi domini come permissivi. Questo viene fatto utilizzando un modello permissivo dichiarazione nel file .te del dominio.
  8. Analizza i risultati e perfeziona le tue definizioni di dominio.
  9. Rimuovi la dichiarazione permissiva quando non vengono visualizzati ulteriori rifiuti in userdebug le build.

Dopo aver integrato la modifica del criterio SELinux, aggiungi un passaggio alla per garantire la compatibilità con SELinux in futuro. In un ideale il processo di sviluppo software, il criterio SELinux cambia solo quando il software le modifiche al modello e non l'implementazione effettiva.

Quando inizi a personalizzare SELinux, verifica innanzitutto le tue aggiunte ad Android. Se hai aggiunto un componente che esegue una nuova funzione, assicurati che il componente soddisfa i criteri di sicurezza di Android, nonché qualsiasi criterio associato creato all'OEM, prima di attivare la modalità di applicazione forzata.

Per evitare inutili problemi, è meglio esagerare e sovracompatibile che troppo restrittiva e incompatibile, il che si traduce in le funzioni del dispositivo. Al contrario, se le tue modifiche saranno vantaggiose per altri, invia le modifiche al criterio SELinux predefinito come patch. Se la patch è applicata al criterio di sicurezza predefinito, non dovrai apportare questa modifica con ogni nuova release di Android.

Esempi di dichiarazioni relative alle norme

SELinux si basa su L4 per computer e, di conseguenza, supporta una serie di macro per risparmiare tempo.

Nell'esempio seguente, a tutti i domini viene concesso l'accesso in lettura o scrittura in /dev/null e lettura 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 };

La stessa istruzione può essere scritta con SELinux *_file_perms macro (abbreviazione):

# 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;

Norma di esempio

Ecco un esempio completo di criteri per DHCP, che esaminiamo 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 criterio di sicurezza di base (domain). Dall'istruzione precedente esempi, DHCP può leggere e scrivere su /dev/null.

Nella seconda riga, DHCP è identificato come dominio permissivo.

Nella riga init_daemon_domain(dhcp), il criterio indica che il protocollo DHCP è generato da init e può comunicare con questo dispositivo.

Nella riga net_domain(dhcp), il criterio consente a DHCP di utilizzare funzionalità di rete comuni del dominio net, come la lettura scrittura di pacchetti TCP, comunicazione su socket e gestione di DNS richieste.

Nella riga allow dhcp proc_net:file write;, il criterio indica DHCP può scrivere su file specifici in /proc. Questa riga mostra L'etichettatura granulare dei file di SELinux. Usa l'etichetta proc_net per limitare l'accesso in scrittura solo ai file in /proc/sys/net.

L'ultimo blocco dell'esempio che inizia con allow dhcp netd:fd use; mostra in che modo le applicazioni possono essere autorizzate interagiscono tra loro. Il criterio indica che DHCP e netd possono comunicare con tramite descrittori di file, file FIFO, socket per datagrammi e flussi UNIX prese di corrente. Il protocollo DHCP può eseguire operazioni di lettura e scrittura solo sui socket datagrammi e su UNIX. e non aprirli né crearli.

Controlli disponibili

Classe Autorizzazione
file 
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
directory 
add_name remove_name reparent search rmdir open audit_access execmod
presa 
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
di elaborazione 
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
funzionalità 
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

ALTRO

E MOLTO ALTRO

regole non consentire mai

Le regole neverallow di SELinux vietano un comportamento che non dovrebbe mai verificarsi. Con i test di compatibilità, Le regole di SELinux neverallow vengono ora applicate a tutti i dispositivi.

Le seguenti linee guida hanno lo scopo di aiutare i produttori a evitare errori relative a neverallow regole durante la personalizzazione. I numeri delle regole qui utilizzati corrispondono ad Android 5.1 e sono soggetti a modifica in base alla release.

Regola 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Vedi la pagina man di ptrace. sys_ptrace consente di ptrace qualsiasi processo, il che consente una grande controllo su altri processi e dovrebbero appartenere esclusivamente al sistema designato descritti nella regola. La necessità di questa funzionalità indica spesso la presenza di qualcosa che non sia destinato alle build rivolte all'utente una funzionalità non necessaria. Rimuovi 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 un codice arbitrario sul sistema. Nello specifico, afferma che viene eseguito solo il codice su /system, che consente garanzie di sicurezza grazie a meccanismi come l'Avvio verificato. Spesso, la soluzione migliore quando si verifica un problema con questo La regola neverallow consiste nello spostare il codice in questione nello /system partizione.

Personalizzazione di SEPolicy in Android 8.0 e versioni successive

Questa sezione fornisce le linee guida per i criteri SELinux del fornitore in Android 8.0 e in alto, inclusi dettagli su SEPolicy di Android Open Source Project (AOSP) e SEPolicy. Per ulteriori informazioni su come viene mantenuto il criterio SELinux compatibili tra le partizioni e le versioni Android, vedi Compatibilità.

Posizionamento del criterio

In Android 7.0 e versioni precedenti, i produttori di dispositivi potevano aggiungere criteri BOARD_SEPOLICY_DIRS, incluse le norme volte ad aumentare le norme AOSP su diversi tipi di dispositivi. In Android 8.0 e versioni successive, l'aggiunta di un criterio a BOARD_SEPOLICY_DIRS posiziona il criterio solo nel fornitore dell'immagine.

In Android 8.0 e versioni successive, il criterio è presente in AOSP nelle seguenti posizioni:

  • system/sepolicy/public. Include il criterio esportato per l'utilizzo delle norme specifiche del fornitore. È tutto sotto controllo con Android 8.0 infrastruttura di compatibilità. Le norme pubbliche devono essere applicate a tutte le release, quindi puoi includere qualsiasi elemento /public nel tuo criterio personalizzato. Per questo motivo, il tipo di criterio che può essere inserito in /public è maggiore limitato. Questo è l'API dei criteri esportate della piattaforma: qualsiasi cosa che con l'interfaccia tra /system e /vendor appartiene qui.
  • system/sepolicy/private. Include i criteri necessari per il funzionamento dell'immagine di sistema, ma di quale criterio relativo all'immagine del fornitore non ne sono a conoscenza.
  • system/sepolicy/vendor. Include i criteri per i componenti essere presenti in /vendor, ma essere presenti nell'albero principale della piattaforma (non specifiche del dispositivo). Questo è un artefatto del sistema di compilazione distinzione tra dispositivi e componenti globali; concettualmente si tratta di un parte dei criteri specifici per dispositivo descritti di seguito.
  • device/manufacturer/device-name/sepolicy. Include criteri specifici per i dispositivi. Include anche le personalizzazioni del dispositivo per che in Android 8.0 e versioni successive corrisponde al criterio relativo ai componenti sull'immagine del fornitore.

In Android 11 e versioni successive, le partizioni di system_ext e prodotto possono includere anche specifici per la partizione. anche system_ext e norme dei prodotti sono suddivisi in pubbliche e private e i fornitori possono utilizzare system_ext come il criterio di sistema.

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. Include il criterio esportato per da usare nelle norme specifiche del fornitore. Installato nella partizione system_ext.
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. Include le norme necessarie per il funzionamento dell'immagine system_ext, ma di quale immagine del fornitore delle norme non dovrebbero esserne a conoscenza. Installato nella partizione system_ext.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS. Include il criterio esportato per da usare nelle norme specifiche del fornitore. Installato nella partizione prodotto.
  • PRODUCT_PRIVATE_SEPOLICY_DIRS. Include i criteri necessari per il funzionamento dell'immagine prodotto, ma di quali norme relative alle immagini del fornitore non dovrebbero esserne a conoscenza. Installato nella partizione prodotto.
Nota: quando viene utilizzato GSI, le partizioni system_ext e product dell'OEM non eseguiranno montare correttamente. Le regole nel sepolicy del fornitore che utilizza system_ext dell'OEM le norme pubbliche del prodotto diventano NOP perché le definizioni dei tipi specifici dell'OEM sono mancante.
Nota: presta particolare attenzione quando utilizzi le norme system_ext e sui prodotti pubblici. Le norme pubbliche fungono da API esportata tra system_ext/product e fornitore. I problemi di compatibilità sono gestiti autonomamente dai partner.

Scenari dei criteri supportati

Sui dispositivi che verranno lanciati 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 passa il CTS su questa immagine di riferimento). Questi requisiti assicurano la separazione tra il framework e il codice del fornitore. Questi dispositivi supportano i seguenti scenari.

estensioni solo immagini del fornitore

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

Come nel caso dei dispositivi che vengono lanciati con le versioni precedenti di Android, aggiungi elementi personalizzazione in device/manufacturer/device-name/sepolicy. Nuove norme che regolano il modo in cui i componenti del fornitore interagiscono (solo) con un altro fornitore componenti devono includere tipi presenti solo device/manufacturer/device-name/sepolicy. Il criterio qui scritto consente il funzionamento del codice sul fornitore e non verrà aggiornato di un OTA solo framework e saranno presenti nel criterio combinato su un dispositivo con l'immagine di sistema AOSP di riferimento.

il supporto dell'immagine del fornitore con AOSP

Esempio: aggiungere una nuova procedura (registrata con hwservicemanager dall'immagine del fornitore) che implementa una HAL definito da AOSP.

Come per i dispositivi che vengono lanciati con le versioni precedenti di Android, esegui personalizzazione specifica del dispositivo device/manufacturer/device-name/sepolicy. Il criterio esportato come parte di system/sepolicy/public/ è disponibile per l'uso e viene spedito come previsto dalle norme per i fornitori. Tipi e attributi di possono essere usate in nuove regole che dettano le interazioni con i nuovi i bit specifici del fornitore, fatti salvi i neverallow limitazioni. Come nel caso del solo fornitore, le nuove norme non verranno aggiornate nell'ambito di un'agenzia di viaggi online esclusiva e sarà presente nelle norme combinate su una dispositivo con l'immagine di sistema AOSP di riferimento.

Estensioni solo per immagini di sistema

Esempio: aggiunta di un nuovo servizio (registrato con servicemanager) accessibile solo da altri processi dall'immagine di sistema.

Aggiungi questo criterio a system/sepolicy/private. Puoi aggiungere altri processi o oggetti per abilitare la funzionalità in un'immagine di sistema partner, a condizione non hanno bisogno di interagire con i nuovi componenti dell'immagine del fornitore, (nello specifico, questi processi o oggetti devono funzionare completamente senza criterio l'immagine del fornitore). Il criterio esportato da system/sepolicy/public è proprio come per le estensioni disponibili solo per le immagini dei fornitori. Queste norme sono parte dell'immagine di sistema e potrebbe essere aggiornata come OTA solo del framework, ma non essere presenti quando si utilizza l'immagine di sistema AOSP di riferimento.

immagine del fornitore estensioni che gestiscono componenti AOSP estesi

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

I criteri per l'interazione tra il sistema e il fornitore devono essere inclusi nella device/manufacturer/device-name/sepolicy fornita nella partizione del fornitore. Questo è simile allo scenario di cui sopra, in cui viene aggiunto il supporto delle immagini del fornitore con l'immagine AOSP di riferimento, ad eccezione dei componenti AOSP modificati richiedono criteri aggiuntivi per funzionare correttamente con il resto del sistema (che va bene purché abbiano ancora il tipo AOSP pubblico etichette).

Criteri per l'interazione dei componenti AOSP pubblici con l'opzione "Solo immagine di sistema" le estensioni devono essere in system/sepolicy/private.

immagine di sistema Estensioni che accedono solo alle interfacce AOSP

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

È un processo simile al system-image-only di estensione, ad eccezione del fatto che i nuovi componenti di sistema possono interagire system/vendor. Il criterio per il nuovo componente del sistema deve vai in system/sepolicy/private, il che è accettabile a condizione che attraverso un’interfaccia già definita da AOSP in system/sepolicy/public (ovvero i tipi e gli attributi richiesti per funzionalità sono presenti). Sebbene il criterio possa essere incluso nel report non potrà utilizzare altri criteri system/sepolicy/private tipi o modifiche (in qualsiasi modo che possa influire sulle norme) in seguito a un'applicazione aggiornamento. Le norme possono essere modificate nell'ambito di un'agenzia di viaggi online esclusiva, ma non saranno presente quando si utilizza un'immagine di sistema AOSP (che non avrà il nuovo sistema ).

immagine del fornitore estensioni che pubblicano nuovi componenti di sistema

Esempio:aggiunta di un nuovo HAL non AOSP da utilizzare in un processo client senza un analogo AOSP (e quindi richiede un proprio dominio).

Simili alle estensioni AOSP Ad esempio, i criteri per le interazioni tra il sistema e il fornitore devono device/manufacturer/device-name/sepolicy la directory spedita nella partizione del fornitore (per assicurarti che il criterio del sistema non sia a conoscenza dei dettagli specifici del fornitore). Tu puoi aggiungere nuovi tipi pubblici che estendono il criterio system/sepolicy/public; questa operazione va eseguita in aggiunta criterio AOSP esistente, ovvero non rimuovere il criterio pubblico AOSP. Il nuovo pubblico tipi possono quindi essere utilizzati per il criterio in system/sepolicy/private e in device/manufacturer/device-name/sepolicy.

Tieni presente che ogni aggiunta a system/sepolicy/public comporta complessità, esponendo una nuova garanzia di compatibilità che deve essere monitorata in un di mapping e che è soggetto ad altre restrizioni. Solo nuovi tipi e le regole di autorizzazione corrispondenti possono essere aggiunte in system/sepolicy/public; e altre dichiarazioni relative alle norme non sono supportati. Inoltre, le nuove i tipi pubblici non possono essere utilizzati per etichettare direttamente gli oggetti nel /vendor criterio.

Scenari delle norme non supportati

I dispositivi che vengono lanciati con Android 8.0 e versioni successive non supportano quanto segue lo scenario delle norme e i relativi esempi.

Aggiuntivo estensioni a immagine di sistema che richiedono l'autorizzazione ai nuovi componenti immagine del fornitore dopo un' OTA basata solo sul framework

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

Simile a nuovo (non AOSP) interazione tra sistemi e componenti del fornitore, tranne il nuovo sistema viene introdotto in un OTA solo framework. Il nuovo tipo potrebbe essere aggiunto al criterio in system/sepolicy/public, le norme esistenti relative ai fornitori non sono a conoscenza del nuovo tipo, in quanto monitora solo le norme pubbliche del sistema Android 8.0. AOSP gestisce tutto questo esponendo le risorse fornite dal fornitore tramite un attributo (ad es. hal_foo), ma le estensioni dei partner attributi non lo sono supportato in system/sepolicy/public, questo metodo non è disponibile per criteri dei fornitori. L'accesso deve essere fornito da un tipo pubblico esistente in precedenza.

Esempio : una modifica a un processo di sistema (AOSP o non AOSP) deve cambiare la modalità di interazione con i nuovi componenti non AOSP del fornitore.

Il criterio nell'immagine di sistema deve essere scritto all'insaputa di specifiche personalizzazioni dei fornitori. Le politiche relative a interfacce specifiche in AOSP sono quindi esposti tramite attributi in system/sepolicy/public, in modo che i criteri del fornitore attivare i criteri di sistema futuri che utilizzano questi attributi. Tuttavia, le estensioni degli attributi in system/sepolicy/public non sono supportato, quindi tutti i criteri che determinano l'interazione tra i componenti di sistema con nuovi componenti del fornitore (e che non sono già gestiti dagli attributi presente in AOSP system/sepolicy/public) deve essere in device/manufacturer/device-name/sepolicy. Ciò significa che i tipi di sistema non possono cambiare l'accesso consentito ai tipi di fornitori nell'ambito di un'agenzia di viaggi online basata solo su framework.