Security Enhanced Android o SEAndroid è il porting di SELinux – creato dalla National Security Agency (NSA) – sul sistema operativo di Google. Annunciato da Stephen Smalley al Linux Security Summit 2011, è disponibile al pubblico. L’intenzione è quella d’incrementare la sicurezza di Android — sulla falsariga del progetto per Linux.
SEAndroid supporta sia YAFFS2, il file system utilizzato fino a Gingerbread, sia Ext4. La soluzione prevede alcune delle principali funzioni di SELinux: integra una politica di Type Enforcement (TE) per autorizzare l’accesso dei processi agli oggetti e un sistema di Multi-Level Security (MLS) per isolare i domini delle applicazioni.
La NSA ha realizzato il porting d’una parte dello userspace di SELinux. Curiosamente, SEAndroid non è stato creato con Android: i sorgenti del progetto sono mantenuti da Fedora, la distribuzione di Red Hat che utilizza SELinux a livello predefinito. Canonical e Ubuntu gli preferiscono AppArmor. L’ultima parola spetta ai produttori.
Come si sottolineava per il porting di PulseAudio, SEAndroid è una soluzione open source di facile installazione su quei sistemi integrati che supportano ufficiosamente Android. Senza l’appoggio dei partner di Google, il progetto è destinato a un uso limitato. Il discorso nella circostanza fa sorridere: sarebbe considerato un hack.
Un ambiente ideale per l’integrazione di SEAndroid sarebbe Linaro con la build di Android che utilizza la toolchain di Ubuntu. Stiamo parlando d’una distribuzione non ufficiale ignorata da Google e perciò esclusa dall’Android Market. Stando a queste condizioni è lecito domandarsi se non sia preferibile optare direttamente per Linux.
Eppure, è innegabile che l’interesse attorno al sistema operativo di Google sia in costante ascesa: la recente disponibilità di PulseAudio e SEAndroid giustificano – almeno, in parte – la tesi di Chris Di Bona, per il quale Android è «il sogno del desktop di Linux diventato realtà». Il problema è nell’evidente dipendenza da Google.
Via | The H Security
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
Tyrael
17 gen 2012 - 13:45 - #1“Curiosamente, SEAndroid non è stato creato con Android: i sorgenti del progetto sono mantenuti da Fedora, la distribuzione di Red Hat che utilizza SELinux a livello predefinito. Canonical e Ubuntu gli preferiscono AppArmor. L’ultima parola spetta ai produttori.”
Cosa significa???
- Che gli sviluppatori utilizzano eclipse o altro su fedora per sviluppare SEAndroid (dov’è la curiosità?)
- Che SEAndroid invece di girare us Android gira su Fedora con il suo kernel (ah ma allora hanno semplicemente cambiato il nome di SELinux in SEAndroid)
- Non importa cosa cavolo sta facendo la NSA, intanto Ubuntu usa apparmor (che non è stato portato ad android) quindi i produttori possono sempre decidere di utilizzare apparmor sui loro prodotti android.
- … ?
Zuk
17 gen 2012 - 14:27 - #2Mai vista cosa più invasiva e invadente di SELinux per l’utente
g_g
17 gen 2012 - 15:45 - #3#1 Forse sei nuovo di questo blog, gli articoli di FM non vanno letti nei dettagli, bisogna prenderli un po’ così, giusto per farsi un idea, sennò si va per finire in inutili flame con l’autore.
Kim Allamandola
17 gen 2012 - 23:03 - #4Solo una piccola nota: Android è GNU/Linux con un userspace minimale che fa
girare un framework, Android appunto, il quale si occupa dell’interazione con
l’utente, dei servizi del sistema ecc ma sotto il cofano a parte un po’ di
patch non nel tree ufficiale Android è GNU/Linux (GNU per la parte di Busybox
e Linux per il kernel) il resto è il framework col suo controllo degli accessi.
SELinux per Android è SELinux per una qualsiasi distro GNU/Linux con un po’ di
ritocchi del caso e quoto Zuk sulla sua invasività e fastidiosità, non a caso
è un progetto USA di nascita governativa… Vi vengono in mente le famose
richieste delle Trusted Extensions?
bpm___
18 gen 2012 - 10:55 - #5@Kim Allamandola SeLinux è un progetto che è nato per permettere un controllo totale delle policy per ogni utente. Questo serve in svariati ambiti nei quali infatti SeLinux è molto apprezzato e non è per nulla invasivo. Diciamo che l’utilizzo su normali desktop non è lo scopo per cui è nato ed è stato sviluppato e sicuramente richiede una configurazione minimale che può anche non essere del tutto banale.
CyberPippo
18 gen 2012 - 18:47 - #6eh si, perché invece apparmor è immune alle leggi sulla sicurezza americane, vero?
Kim Allamandola
18 gen 2012 - 19:11 - #7@bpm___ #5
SeLinux ha come scopo primario il controllo delle syscall, questo include
anche il desktop ed è assolutamente invasivo, ti basta provare Fedora che
ha scelto SeLinux tempo fa per constatarlo; anche le mailing list dove si
leggeva “boota con selinux=0 e risolverai tutti i tuoi problemi” sono un
buon indizio :-)
Sono sempre un po’ troppo acido ma vedo che ha troppi piace avere le porte
blindate sui muri di carta…
@CyberPippo #6
Scusa, che c’entra? AppArmour è assai più gestibile di SeLinux ed opera in
maniera assai meno invasiva. Io ho semplicemente catalogato SeLinux come le
Trusted Extensions, software scritto da o su commisione di enti governativi
USA, come software ridicolo per l’equazione costi-benefici e per la complessità
che ha. Del resto è in USA che sequestrano un portatile ad uno studente perché
un suo collega “dice” alla polizia che “è un tipo strano che entra nel cuore
del sistema e da li lancia comandi” (Alt+F1 per inciso), è in USA dove una
scuola s’è permessa di mettere un braccialetto elettronico agli studenti
obesi per “monitorare le loro attività e redarguirli per i loro comportamenti”,
è negli USA dove in alcune scuole ed altre istituzioni si forniscono computer
con software spia nelle WebCAM dei portatili ecc.
La mia nota è solo che Android è GNU/Linux non è un OS a se e che SeLinux è
più che altro un’americanata che una figata, tutto qui.
CyberPippo
18 gen 2012 - 20:48 - #8definisci “invasivo” sennò stiamo qui a parlare di aria fritta come al solito
poi il confine tra americanata e figata qui è molto labile dal momento che sia apparmor che selinux sono dei giocattoli se paragonati ad altri sistemi MAC
bpm___
19 gen 2012 - 11:05 - #9@Kim Allamandola selinux può essere usato per il desktop ma è nato per sistemi in cui è richiesto un controllo fine delle policy degli utenti. Che poi venga usato anche in ambito desktop quello è un altra cosa.
Apparmor è sicuramente meno invasivo ma non ha il controllo di SeLinux. Infatti Apparmor è nato per essere un sistema più semplice da utilizzare quando non è richiesto la complessità di SeLinux.
Non è un caso che in molti sistemi critici basati su Linux si usa spesso SeLinux per limitare i danni in caso di accessi non autorizzati.
Poi cosa centrano gli esempi Americani con questo prodotto? SeLinux è nato per gestire quasi completamente cosa un utente può e non può fare, in sistemi in cui questo è richiesto.
Kim Allamandola
19 gen 2012 - 12:04 - #10@CyberPippo #8
Un software che sostanzialmente vuole “conoscere” ogni applicazione che gira
per giudicare se una da chiamata a funzione è legittima o meno lo ritengo
assai invasivo, mi ricorda tanto il classico tema aziendale dove certi manager
vorrebbero un report istante per istante senza considerare il tempo che ci
vuole per preparare e scrivere il report anziché lavorare… In altri termini
vedo SeLinux come qualcosa di troppo complesso rispetto alla complessità di
un sistema moderno per essere considerato accettabile, se si ritiene SeLinux
sia necessario allora è necessario riprogettare il funzionamento del sistema
perché una simile soluzione è eccessivamente scomoda da gestire…
Le Trusted Extensions di Solaris che ho citato sono un altro esempio a mio
avviso “da burocrati” piuttosto che da tecnici, qualcosa che è un regolare
bagno di sangue; ritieni serva? Bene allora vuol dire che il sistema attuale
non è in grado di soddisfare i tuoi requisiti e va riscritto da zero altrimenti
fanne a meno…
Spero di aver risposto…
@bpm___ #9
Se non ricordo male l’obbiettivo dell’NSA (da cui la mia bollatura di
Americanata) era di avere SeLinux ovunque ovvero anche sui desktop, poi mi
sono disinteressato al tema ritenendolo assurdo e non più di mio interesse
operando all’epoca su FreeBSD prima e Solaris poi, non so se abbiano aggiustato
il tiro…
Quel che non mi va è lo scopo di SeLinux, se vuoi un simile controllo devi
fare un framework su cui tutte le applicazioni si basano che nativamente
prevede nella sua architettura un controllo simile (Android è diverso ma
soddisfa un concetto simile) altrimenti inserirlo nei sistemi attuali le cui
architetture sono state pensate tra gli anni ‘80 e ‘90 e da allora sempre
più o meno ferme son rimaste è troppo oneroso… Lo schema classico dei
permessi, le ACL POSIX e poco altro sono il massimo che puoi pretendere IMO
dai sistemi attuali. Non ti basta? Ok, è tempo allora di riprogettare l’OS!
Eliminiamo il concetto di filesystem, il filesystem diventi solo un modo di
visualizzare i dati, implementiamo un sistema che gestisca lo storage con
degli hook opportuni per le varie applicazioni e che nativamente disciplini
ogni cosa, una mossa simile mi può piacere, queste soluzioni no…
bpm___
19 gen 2012 - 15:12 - #11@Kim Allamandola
Lo scopo di SeLinux era fornire, per chi ne avesse bisogno, delle policy più fini per cercare di mitigare i danni derivanti principalmente da accessi non autorizzati. SeLinux è da sempre stato indirizzato a sistemi critici (magari anche desktop ma il target rimaneva sempre quello dei sistemi critici). Solo “recentemente” è stato introdotto di default in varie distribuzioni. Ma non per pressioni dell’NSA. Il problema per gli utenti comuni è che selinux rimane complesso da configurare e quindi, seppur molto potente, il target dovrebbe rimanere quello originale, ovvero sistemi in cui è indispensabile il massimo livello di sicurezza.
E’ vero che l’os dovrebbe essere ripensato. Però, al giorno d’oggi, se si vuole utilizzare un sistema linux in ambienti critici questo (o soluzioni analoghe) sono necessarie (e in molti casi anche obbligatorie).
tosky
20 gen 2012 - 15:55 - #12Caro Kim, i tuoi pregiudizi (e quelli di molti che dicono di disattivarlo) risalgono all’epoca delle decisione (sciagurata) di Fedora di uscire con la politica piu’ restrittiva per tutto. Dove ovviamente non funzionava una cippalippa.
Adesso la politica e’ “targeted”: limitazione di specifichi servizi dove serve. E funziona, tanto che ci sono attacchi che funzionano se esplicitamente SELinux e’ disattivato
E gli sviluppatori sono pronti a integrare nuove regole *se* i bug vengono segnalati…
Kim Allamandola
20 gen 2012 - 21:42 - #13@bpm___ #11
Questo è vero ma preferirei aspettare di avere un OS ridisegnato (con un buon
stimolo per farlo, non coi giochini di symlink in giro!), SeLinux su quel che
amministro non lo gradisco.
@tosky #12
Vero anche questo, tuttavia la politica di “andarci più morbidi” mi pare del
tutto assurda: se il sistema funzioni che vada, se rompe che non vada. Se c’è
un baco di sicurezza che questo sia risolto, non aggirato con una pezza tanto
per andare avanti… So che nel Mondo Reale® talvolta può far comodo una
soluzione simile ma poiché tutte le soluzioni “temporanee” o “parziali” via
via che passa il tempo restano li preferisco avere un problema conclamato oggi
che non un mezzo-problema domani!
CyberPippo
21 gen 2012 - 01:04 - #14Ma non si tratta di “bachi di sicurezza” ma di punti deboli legati all’architettura del sistema. Ci sono degli attacchi che si possono portare con successo su qualunque sistema unix “standard”. Allora tu suggerisci di ridisegnare il sistema, ma io non vedo il perché dal momento che selinux JustWorks(TM)
Io la penso così, almeno finché non mi si portano degli esempi di problemi che selinux indirizza ma che non riesce a risolvere.
Kim Allamandola
21 gen 2012 - 12:09 - #15@CyberPippo #14
È presto detto: dal mio modo di vedere un punto debole di un’architettura è un
baco. Non importa che sia qualcosa by-design ovvero sfruttabile tramite il
normale funzionamento dell’algoritmo o che sia un problema di codice che può
permettere di alterare entro certi limiti il funzionamento di un software a
runtime: è qualcosa di sgradito, è qualcosa che ha implicazioni di sicurezza,
è un baco. Da ciò ne segue che il baco si risolve non lo si tappa con altro
software.
Per queste ragioni il design di SeLinux non mi va: AppArmour è assai meno
invasivo e mi basta il resto delle energie andrebbe dirottato sul redesign
della vecchia architettura, sul ripensamento dei filesystem, di come le singole
applicazioni accedono alle risorse del sistema ecc. Far altro è perdere tempo
in sofisticate pezze di cui oggi non c’è tutto stò bisogno ed un domani è
opportuno non ci sia proprio grazie ad un sistema ammodernato.
Ma dico, possibile che a parte ingegnerizzazione di cose fatte negli anni ‘80
od ancor prima, scemate o obbrobri non si riesca più a fare? Il cervello
umano tra le riforme scolastiche e la TV s’è così tanto bruciato negli ultimi
30-40 anni!? O forse s’è estesa la moda edilizia italica dove non si può mai
rifare qualcosa da zero, solo andare avanti con costose e complesse pezze e
tacconi sino a quando il terremoto o altro disastro di turno non butta giù
tutto o magari non si può cambiare perché modificare i propri schemi mentali
costa fatica e nessuno vuol accettare questo?
0xdeadbeef
21 gen 2012 - 19:05 - #16E’ incredibile come si possa scrivere 5 commenti senza dire niente.
Kim Allamandola
22 gen 2012 - 21:59 - #17@0xdeadbeef #16
Facciamo 6, tu invece cosa dici? Hai qualche valida argomentazione contro il
fatto che Android sia GNU/Linux o contro il fatto che se SeLinux è necessaria
allora sia opportuno riprogettare l’OS riformulando l’ottimo ma forse un pelo
obsoleto paradigma POSIX (mai del tutto rispettato) e successive aggiunte?
0xdeadbeef
24 gen 2012 - 01:34 - #18Anzitutto l’obiettivo di SELinux non è il “controllo delle syscall” o altri dettagli implementativi, ma la riservatezza dei dati, secondo un modello simile al Bell-LaPadula (con MAC-MLS/MCS a livello kernel) cosa che AppArmor - sistema che SuSE usò al posto di SELinux perché altrimenti avrebbe dovuto buttare il proprio ReiserFS - non può garantire per design. Inoltre SELinux può simularne il comportamento con la policy targeted.
Poi neanch’io trovo senso a questa storia dell’invasività, l’overhead è quasi nullo e comunque non so come si faccia a dire che il tempo impiegato a garantire la sicurezza sia tempo perso. E lascerei stare anche questa storia di SELinux sui desktop che non si può sentire. Il motivo per cui RH in parte lo fa su Fedora è sia perché ha bisogno di feedback sulle policy, sia perché chi fa i pacchetti deve garantire che questi effettivamente funzionino.
Sulla facilità di configurazione, dico solo che nessun sano di mente metterebbe la sicurezza di un servizio che gestisce dati personali (codici bancari, carte di credito ecc…) nelle mani di un principiante senza know how.
Ma al di là delle preferenze personali, la realtà - come credo bpm e cyberpippo cercavano invano di farti capire - è che sia SELinux che AppArmor sono due soluzioni che indirizzano due classi di problemi diverse, dipendenti dai tipi di clientela che RedHat e l’allora SuSE avevano. La prima punta ad avere un sistema di sicurezza delle informazioni completo in ogni suo aspetto, con tutti i pro e i contro, la seconda cerca solo di proteggere la macchina locale, con relativi pro e contro.
SELinux è un palleativo? Non si capisce né il motivo né dall’alto di quale esperienza di utilizzo di SELinux parli, e comunque io mi rifaccio al vecchio detto “non aggiustarlo se non è rotto”. E a me SELinux funziona egregiamente.
E siamo arrivati a 18 commenti per dire delle ovvietà. Al tuo prossimo commento ti dico subito che hai ragione tu, così tagliamo corto.