La scelta implementativa di SE-linux

Ho voluto realizzare un compromesso tra sicurezza e manutenibilità del sistema. Nei sistemi di derivazione Red Hat, ovvero Fedora, CentOS e Red Hat Enterprise Linux, esistono due tipologie di policy preconfezionate disponibili con la distribuzione: la targeted e la strict. La modalità targeted ha il compito di proteggere e confinare i daemons, lasciando aperto tutto quello che non è esplicitamente confinato (quello che non è esplicitamente confinato è chiamato anche unconfined_t). Nella modalità strict ogni singolo programma e ogni singolo “ambiente” è confinato, dovendo impostare delle regole di abilitazione (si chiamano domain transition).

Sono stato combattuto tra quale delle due modalità utilizzare: sicuramente la prima è più facile da gestire, ma ha dei problemi a “confinare” i system administrators, mentre la seconda offre una sicurezza senza dubbio maggiore a livello militare, ma necessita di una preparazione sistemistica notevole, che normalmente operatori non hanno. Continua a leggere

Protezione dei files con SE-Linux

Un sistema ad accesso mandatorio, quale SE-Linux, permette di proteggere in maniera esaustiva un computer contenente files e dati sensibili. La sua gestione è però molto onerosa in quanto è necessario possedere delle solide conoscenze non solo dell’ambiente Linux, ma anche di sicurezza, sistemi mandatori e come funziona al suo interno SE-Linux. Spesso però da un lato non si necessita di tanta sicurezza, dall’altro non si dispone di sufficiente personale altamente specializzato per riuscire a gestire sistemi con dati sensibili. Questo whitepaper, basato su un caso reale, vuole illustrare una metodologia che coniuga alta sicurezza con una gestione di un ambiente unix non differente da quella tradizionale. Il documento si rivolge agli amministratori di sistema che abbiano solide basi di Linux e di sicurezza informatica, con una conoscenza di base di SE-Linux. Continua a leggere

SPNEGO

Come abbiamo accennato precedentemente, le GSSAPI foriniscono un set di API generiche che si astraggono dal meccanismo di autenticazione sottostante. Quando due applicazioni parlano tra loro attraverso le GSSAPI e sfruttano lo stesso meccanismo di autenticazione, si dice che hanno stabilito un contesto di sicurezza (security context). Il problema di questo meccanismo è che le due entità devono sapere a priori quale meccanismo di autenticazione hanno a disposizione e quindi quale possono usare: GSSAPI non prevede un meccanismo di “handshake” tra i due peer per sapere quale meccanismo di sicurezza hanno in comune e stabilire quindi un security context.

Il Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) è stato creato appositamente per determinare, durante una connessione tra due peer, quali sono i meccanismi di autenticazione disponibili e selezionare il miglior meccanismo comune. SPNEGO viene usato in Windows 2000 per negoziare quali sono i meccanismi di Continua a leggere

GSSAPI

Anche se non fanno parte direttamente del protocollo Kerberos, descrivere le GSSAPI è propedeutico alla comprensione del resto del libro.

Le Generic Security Service Application Programming Interface  sono un framework che fornisce servizi di sicurezza alle applicazioni.

Lo scopo della nascita delle GSSAPI era creare un “abstraction layer” attraverso delle API standard per l’autenticazione, in modo che ogni programma potesse implementare l’autenticazione astraendosi dal sistema di autenticazione sottostante. Continua a leggere

1 7 8 9 10 11 22