logo

Pagina iniziale / Photo Album / Statistiche / Contattami / Login
Computer, SysAdmin
pam_unix2 e call_modules
PAM è un sistema per permettere grande flessibilità nella gestione degli account di un sistema unix. Si può fare in modo da verificare le credenziali di un utente dai classici file /etc/passwd locali oppure via NIS o LDAP o tramite l'autenticazione del dominio Windows o altro ancora.

PAM è costituito da vari moduli distribuiti sotto forma di librerie che hanno una certa API ben definita e richiamabile dalla libpam che si collega agli eseguibili che vogliano utilizzare PAM.

Ci sono vari file di configurazione in /etc/pam.d e /etc/security che specificano quali moduli chiamare, in che sequenza, e come comportarsi a seconda dall'esito di un certo modulo. Ad esempio si può dire che un utente deve esistere su LDAP, oppure che può esistere su LDAP ma se non c'è allora va controllato /etc/passwd.

Il modulo principale è quello chiamato pam_unix.so che si occupa appunto dell'autenticazione su /etc/passwd e /etc/shadow, ma su alcune distribuzioni, come la SuSE, viene sostituito da pam_unix2.so.

Il modulo pam_unix2 ha un file di configurazione chiamato /etc/security/pam_unix2.conf nel quale è possibile specifire le opzioni da usare per questo modulo. Tra le opzioni ce n'è una chiamata call_modules. La pagina di manuale di pam_unix2 (http://manpages.unixforum.co.uk/man-pages/linux/suse-linux-10.1/8/pam_unix2-man-page.html) non è proprio chiara su cosa faccia questa opzione, ma mi pare di capire che gestisca una specie di fallback nel quale la ricerca in /etc/passwd è l'ultima risorsa. Ad esempio: chiama il modulo winbind, ma se non trovi l'utente lì allora usa il normale /etc/passwd.

Io personalmente non lo capisco: non capisco perché un modulo di PAM (che è fatto apposta per gestire vari moduli a cascata secondo varie regole) debba esso stesso mettersi a realizzare delle proprie regole che possono benissimo esprimersi con la normale sintassi del PAM.

Chi me lo spiega?
by giuseppe
Tuesday, 17 Gennaio,2012, 22:41
commenta commenta ( 22Visite )  |  [ 0 trackbacks ]  |  
( 0 / 0 )

Tracciare quanto succede in una applicazione Java è certamente molto importante per molti motivi: per gli sviluppatori contano molto i messaggi di debug, per i sistemisti potrebbero contare i messaggi di informazioni che pilotano le scelte del programma, per l'utente i messaggi d'errore.

Ci sono due metodi molto diffusi per gestire i log in java. Uno è stato realizzato dal gruppo apache e si chiamata log4j, l'altro è incluso nel package java.util.logging della JVM standard. Qui tratto alcuni aspetti della seconda implementazione, quella inclusa in Java.

I messaggi prodotti dall'applicazione sono ordinati secondo un livello di importanza che va dal molto particolareggiato al meno dettagliato. In genere i messaggi meno dettagliati sono quelli gravi o d'errore, mentre quelli più di dettaglio sono quelli di debug.

L'applicazione deve inviare i messaggi ad un oggetto chiamato Logger. Il logger a sua volta li manda a uno o più handler i quali li salvano da qualche parte. Ci sono handler per l'invio dei messaggi via socjet, oppure per la scrittura sulla console o ancora per il salvataggio su file. Oltre a logger e handler, ci sono i formatter che sono necessari per formattare correttamente il messaggio da inviare. Questi ultimi sono gestiti direttamente dagli handler.

Ogni logger ha quindi un livello minimo (da FINEST a SEVERE) che indica se inoltrare o meno i messaggi all'handler. Se il livello del messaggio è superiore a quello impostato per il logger, allora il messaggio viene processato.

Quando il logger riceve un messaggio di un livello tale da tenerlo in considerazione, chiama i vari handler e passa loro il messaggio con i relativi argomenti. Ma, a differenza di quanto previsto in log4j, anche gli handler hanno un loro livello e quindi anch'essi stabiliscono, singolarmente, se processare o meno l'informazione. E questo livello degli handler ha un valore predefinito che varia. Ad esempio, ConsoleHandler ha livello minimo predefinito INFO, mentre SocketHandler ha livello minimo predefinito ALL.

Una volta che l'handler decide di processare il messaggio, lo passa al formatter e poi lo memorizza in base alle proprie caratteristiche.

Facciamo un esempio di inizializzazione di un logger con due handler:

       logger = Logger.getLogger(ScanApp.class.getPackage().getName());
        logger.setLevel(Level.FINE);

        try {
            Properties config = new Properties();
            config.put("java.util.logging.ConsoleHandler.level", "FINE");
            config.put("java.util.logging.FileHandler.level", "FINE");

            ByteArrayOutputStream output = new ByteArrayOutputStream();
            config.store(output, null);
            output.close();
            ByteArrayInputStream input = new ByteArrayInputStream(output.toByteArray());
            LogManager.getLogManager().readConfiguration(input);

            ConsoleHandler ch = new ConsoleHandler();
            FileHandler fh = new FileHandler("%t/JavaLogging-%u.log");
            fh.setFormatter(new SimpleFormatter());
            logger.addHandler(ch);
            logger.addHandler(fh);
        }
        catch (Exception e) {
            System.err.println("Errore durante la configurazione del logging: "+ e.getMessage());
            e.printStackTrace();
        }

Dopo aver eseguito queste di codice, poiché abbiamo impostato il livello di log sia nel logger che in entrambi gli handler, potremo inviare messaggi di quel livello con l'istruzione:

logger.fine("Ho impostato il livello di log");

Purtroppo non si può sapere veramente quale sia il livello minimo di log attuale perché il metodo isLoggable() del logger non verifica che anche gli handler siano allineati su quel lilvello. Per questo si deve prendere l'elenco dei vari handler collegati al logger e per ciascuno di essi invocare lo stesso metodo isLoggable().
by giuseppe
Wednesday, 11 Gennaio,2012, 13:01
commenta commenta   |  [ 0 trackbacks ]  |  
( 0 / 0 )

Generico
Musica!
In questi giorni, la radio non trasmette le solite trasmissioni di intrattenimento poiché chi le tiene si è preso qualche giorno di ferie. Al posto di queste trasmissioni si ascolta la musica. Ed è musica bellissima: ci sono pezzi di secoli fa come «Wish you were here» o più recenti come alcuni brani di Dee Dee Bridgewater, o anche quella canzone che ci piace tanto ma della quale non conosciamo l'autore o il titolo.
Io sto riscoprendo la musica. Anziché rattristarmi con i radiogiornali o con le trasmissioni di approfondimento, ascolto nuovamente la musica e sono felice. Che bello.
E allora uno si chiede: dove sono finiti i dischi? Perché una volta ne ascoltavo tanti e adesso non più? Oppure, forse, non è un discorso di dischi nascosti, ma è anche un discorso di tempo libero.
Però, più che di tempo libero, è questione anche di costo della musica. Sia che la si prenda online, sia che si entri in un negozio per comprare un CD, non si tratta di un piccolo esborso. Ed è certamente vero che ci sono produzioni «alternative» che offrono prodotti di qualità a prezzi abbordabili, ma sono decisamente una minoranza.
by giuseppe
Thursday, 22 Dicembre,2011, 15:55
commenta commenta ( 4Visite )  |  [ 0 trackbacks ]  |  
( 0 / 0 )

Computer
shebang
Qualche giorno fa, nella lista debian-italian, ho pensato di rispondere a questa domanda relativa allo shebang, la cui utilità veniva messa in dubbio:

> Si ma mi sembra venga ignorato se ad esempio metti il tuo file in
> crontab oppure lo esegui con at (a meno che appunto non lo richiami con
> /bin/bash /path/tuo/bash/script)

questo è quello che ho risposto:

Non mi pare. Prova: fai uno script e lo lanci da cron; dentro lo script controlli la variabile SHELL e scopri qual è.

La shell corrente, se invochi un eseguibile con il bit «x» a posto, non sta ad aprirlo per guardare se sia un binario o da interpretare, ma invoca la chiamata execve() di sistema. Questa chiamata fa la verifica in questione e chiama l'interprete giusto, ignorando completamente quale eseguibile o interprete l'abbia invocata.

Se invece usi il comando "sh /path/tuo/script" stai facendo una cosa diversa: la shell non invoca la execve() e si occupa invece di interpretare il file passato come argomento.

Difatti, la funzione execve(), una volta che capisce che l'eseguibile non è un binario, ma va interpretato, esegue l'interprete trovato nello shebang aggiungendovi in fondo il nome del file da interpretare e tutti gli eventuali argomenti ricevuti.

Il fatto che cron e at utilizzino una shell, è scelta obbligata in quanto permettono di avere comandi complessi al posto di limitarsi ad eseguire un solo comando. L'interpretazione di questi comandi è demandata alla shell predefinita. Ma questa a sua volta userà execve().

«man execve» per alcune informazioni in proposito.

La discussione completa è qui.
by giuseppe
Sunday, 18 Dicembre,2011, 11:22
commenta commenta   |  [ 0 trackbacks ]  |  
( 0 / 0 )

Faccio una piccola introduzione alla firma digitale così come impiegata nella posta elettronica. L'idea di base è che un certo messaggio sia valutabile come autentico o meno, quindi si applica una firma certificata da qualche ente riconosciuto.

Ogni email è composto da due parti: l'intestazione e il corpo. Il corpo a sua volta può essere solo testo oppure in formato mime, cioè non testo e, eventualmente, strutturato in varie parti. Il mime permette ad esempio di avere email con allegati: la prima parte è il testo, le altre sono allegati (semplificando). Oppure il mime permette di avere un email che è sia in formato testo che in formato html, lasciando poi al ricevente la scelta su come visualizzarlo. Il mime permette anche di inserire una firma: lo si può fare allegando un documento firmato, oppure un documento normale e una firma a sé stante. Nel primo caso il mime avrà una sola parte, nel secondo sarà composto da due.

La firma può essere di vari tipi. I più diffusi sono la S/MIME e la GPG. Si tratta di due cose distinte e non tutti i programmi di posta sono in grado di gestirle entrambe.

Il formato S/MIME prevede che la firma sia effettuata con un certificato in formato PKCS, cioè quello dei file .p12 o delle smartcard. Il formato GPG invece utilizza le chiavi di gpg che possono anch'esse essere memorizzate in una smartcard (meno diffusa).

Finora ho fatto riferimento al certificato, ma in realtà sono necessarie due componenti: una parte chiamata chiave privata che rimane in possesso di chi applica la firma, una parte chiamata chiave pubblica che viene diffusa a tutti quelli che devono verificarla. I normali certificati contengono la chiave pubblica di una persona e sono firmati con la chiave privata di un ente certificatore. Il certificato contiene in realtà anche la parte pubblica della chiave del certificatore, in modo da verificare che in effetti il certificato sia stato emesso correttamente. Riassumendo: si deve possedere una chiave privata e una pubblica,  eventualmente firmata da un certificatore. I sistemi operativi (ma anche i programmi di posta) hanno un elenco di enti certificatori, catalogati a seconda dal grado di fiducia che gli si vuole dare.

Per applicare la firma si deve fare in modo che il programma di posta possa colloquiare con il dispositivo di sicurezza che contiene la chiave e il certificato. Se il certificato e la chiave pubblica sono su file, allora il programma ha già un suo sistema per accedervi, altrimenti sarà necessario fornire un driver. È stata definita un'API per fare in modo che i programmi possano comunicare con i dispositivi, cioè in genere i lettori di smartcard o i token USB crittografici. C'è poi una seconda API per colloquiare con le varie smartcard. La prima si chiama PC/SC, la seconda Cryptoki PKCS11. Infine, all'interno del PKCS11 c'è una serie di comandi che riguardano la crittografia, chiamati PKCS15. Il PKCS11 serve a comunicare genericamente con il dispositivo, il PKCS15 serve a gestire specificatamente le operazioni di firma.

Quindi è necessario che in Thunderbird si configuri un dispositivo di sicurezza, in genere specificando la libreria (o dll, su Windows) che ha una interfaccia PC/SC e che permette di accedere al token.

Ad esempio, in thunderbird 7.0.1, si deve aprire la finestra delle impostazioni, selezionare l'icona «avanzate», poi la linguetta «Certificati», infine il bottone «Dispositivi di sicurezza». Ce ne sono vari. Se si seleziona quello PKCS11 e poi si preme il pulsante «carica» si può aggiungere un nuovo dispositivo di sicurezza, cioè una libreria che ne piloti l'accesso.

Su Linux la libreria in questione è quella del progetto OpenSC. Si devono quindi installare i vari pacchetti che ne fanno parte. Tra questi, se non ricordo male, ce n'è proprio uno che serve a collegarsi ai prodotti della Mozilla Foundation, come Firefox e Thunderbird. Oltre al modulo generico OpenSC si dovrebbe anche installare i pacchetti specifici per il lettore che si possiede, come ad esempio libacr38u o libacsccid1 o libgempc430.

Una volta che si ha installato tutto, con il comando «pcsc_scan» si potrà vedere se OpenSC riesce a comunicare con il lettore, se riconosce il token (cioè se il suo ATR è tra quelli gestiti). Si potrà poi provare anche la parte di firma con il comando «pkcs15-tool --list-keys».

Se la cosa funziona, allora si può completare la configurazione con Thunderbird e vedere se il programma accede al token.

Aggiungo solo alcune note di teoria della firma: il dispositivo di firma non fa mai uscire la chiave privata, vale a dire che è possibile leggere quella pubblica ma non quella privata. Per firmare un documento, poiché la comunicazione con le smartcard è molto lenta (va al massimo a 9600 baud) si fa in modo da calcolare l'impronta del documento da firmare, e si fa firmare questa impronta trasferendola al dispositivo di firma. Ad esempio è possibile aggiungere una seconda firma, semplicemente prendendo la stessa impronta e facendola firmare ad una seconda persona. Oppure esistono le controfirme, cioè le firme che vengono applicate alla firma di qualcun altro, oppure le firma utilizzare per rinnovare una firma precedente.

A questo proposito, preciso che tutto quello che ha a che fare con la firma digitale ha una scadenza. Hanno una scadenza i certificati, ha una scadenza la firma apposta, a volta ha una scadenza anche la chiave privata. Il motivo è lo stesso che fa scadere le carte d'identità o quelle di credito: limitare i danni nel caso che la carta sia rubata.

I certificati contengono varie informazioni. Oltre alla chiave pubblica del soggetto, alla firma dell'ente, alla data di scadenza, sono anche presenti una serie di informazioni che indicano come verificare se il certificato è ancora valido. Esiste difatti un meccanismo di revoca che permette agli enti di pubblicare elenchi di certificati revocati prima della loro normale scadenza. In questo modo, se lei perde una carta e comunica all'ente di revocare la firma, il programma di posta che validerà un documento firmato successivamente alla data di revoca saprà che la firma non è in realtà valida.

Spero di aver chiarito almeno gli aspetti principali della firma elettronica e della specifica configurazione di Thunderbird. Aggiungo alcuni collegamenti per un approfondimento su questo secondo punto:
http://www.opensc-project.org/opensc
http://opensignature.sourceforge.net/blog/index.php?id=3204e0
by giuseppe
Saturday, 29 Ottobre,2011, 17:03
commenta commenta   |  [ 0 trackbacks ]  |  
( 0 / 0 )


Altre notizie

powered by pppBLOG v 0.3.11