Sembra che per SELinux non ci sia proprio un momento di tranquillità: nei giorni scorsi la presentazione e la promessa di inclusione nel mainline kernel di una soluzione alternativa al sistema originariamente sviluppato dall’NSA, oggi, invece, un’accesa discussione sulle differenze tra la sicurezza garantita da SELinux e quella offerta da un sistema OpenBSD.
I principali argomenti che vengono portati contro SELinux si concentrano attorno alla sua complessità ed alla difficoltà nella definizione delle policy, processo che, a dire il vero, è stato semplificato anche grazie all’introduzione di tool come polgengui; gli utilizzatori di OpenBSD intervenuti nella discussione hanno sottolineato come la prima cosa che la gente “normale” faccia con SELinux sia spegnerlo, facendo notare anche come la facilità con cui esso può essere spento sia un’altra imperfezione del suo modello di sicurezza.
Continua a leggere: OpenBSD vs SELinux: la complessità è un problema?
SELinux è estremamente potente ma, al tempo stesso, decisamente complesso. Partendo da questa considerazione si capisce perché Novell abbia proposto AppArmor come alternativa al noto sistema sviluppato dall’NSA, perché Canonical abbia deciso di includere il software di Big-N nelle sue distribuzioni e perché esistano tomi come “SELinux by Example“…
Questo risentimento generalizzato ( a volte ingiustificato ) nei confronti di SELinux ha recentemente preso la forma di un nuovo patchset per Linux che introduce il supporto al famigerato mandatory access control. Sotto l’acronimo di SMACK ( Simplified Mandatory Access Control Kernel ) troviamo un sistema che, utilizzando etichette per file, processi od altri tipi di risorse, un minimo supporto da parte degli applicativi ed un pizzico di configurazione, si candida a sostituto di SELinux, essendo una sorta di superset di quest’ultimo.
Stando alle considerazioni di Andrew Morton, SMACK potrebbe trovar posto nel mainline kernel già a partire dalla prossima versione ( 2.6.24 ) ma, vista la criticità di qualsiasi cosa legata alla sicurezza, immagino che le polemiche per una decisione simile non tarderanno ad arrivare.
[ via KernelTrap ]
Interessati alla creazione di policy SElinux tramite una comoda interfaccia utente? Red Hat Magazine ha pubblicato un articolo estremamente chiaro ( e, pur ritenendomi un profano dell’argomento, completo ) sulla generazione di regole per SElinux con l’utilizzo di polgengui, un tool GTK2 che rende molto più agevole il lavoro dei sysadmin particolarmente scrupolosi.
Di seguito qualche screenshot di polgengui in azione. Buona lettura!
[ via OSNews ]
RSBAC, acronimo di Rule Set Based Access Control, è una soluzione per incrementare la sicurezza di un sistema Linux e, a grandi linee, svolge lo stesso ruolo di SELinux ( pur basandosi su teorie differenti ); recentemente è stata rilasciata una nuova versione del ramo stabile ( 1.3 ) la cui novità maggiore è sicuramente l’implementazione del caching dei file descriptor, una modifica che incrementa in maniera netta il livello prestazionale di RSBAC e che lo parta al pari delle altre soluzioni per l’hardening.
Approfittiamo di questa notizia per segnalare anche la disponibilità di mod_rsbac, un modulo per Apache che sostituisce SuExec offrendo un più alto livello di separazione dei privilegi ed una diminuzione dell’overhead normalmente generato dal forking.
[ via OSNews ]
Una decina di giorni fa vi avevamo segnalato un confronto tra SELinux e le Trusted Extesions di Solaris, nel quale venivano sottolineate le differenze più sostanziali tra questi due sistemi di hardening utilizzati rispettivamente da Linux e Solaris. Com’era prevedibile, l’articolo ha suscitato qualche polemica a causa della parzialità di alcune affermazioni espresse dall’autore del pezzo ( un dipendente di Sun ).
Tra i link segnalati durante le discussione scaturita ne ho apprezzato uno in particolare, intitolato “Trusted Operating Systems” che, con uno stile simile a quello del primo articolo segnalato, affronta il discorso dei sistemi operativi “sicuri”, evidenziando alcuni punti di forza di SELinux non presentati nel pezzo originale.
Spero possa tornare utile anche a tutti i lettori che avevano trovato interessante la prima segnalazione.
[ via OSNews ]
Tempo fa avevamo parlato di AppArmor, framework opensource sviluppato da Novell per aumentare la sicurezza di un sistema Gnu/Linux. Il sistema che vorrebbe porsi come alternativa “user friendly” a SELinux è da poco presente nei repository di Ubuntu Feisty. In questo modo gli utenti della prossima release di Ubuntu potranno avere un’alternativa per mettere in sicurezza il proprio sistema. Ma la notizia dell’ingresso di AppArmor nei repository di Feisty non ha suscitato pareri positivi e c’è già chi contesta la validità e la sicurezza del framework Novell.
Staremo a vedere chi tra SELinux e AppArmor conquisterà le attenzioni dei “security addicted” che usano la distribuzione umana, intanto anche se si tratta di un confronto di parte consiglio la lettura della panoramica sui due sistemi realizzata da Novell.
[Via | Tuxmachines & Arun’s Blog]
Approfittando del fatto che sia Solaris che RHEL sono in fase di valutazione per la certificazione Common Criteria, Sun ha pensato di pubblicare un corposo documento che evidenzia le differenze architetturali dei due sistemi operativi, relativamente ai meccanismi di sicurezza implementati.
Pur non essendo una lettura estremamente tecnica è comunque richiesta un’infarinatura sul funzionamento di SElinux e Solaris Trusted Extensions per poter comprendere al meglio le differenze evidenziate dall’articolo; alcuni passaggi sono chiaramente di parte ma si tratta comunque di un buon approfondimento, soprattutto per chi si interessa di sicurezza ed al design dei sistemi operativi.
[ via OSNews ]