From 8a8929a1e656fb97062b35f197a3b985201cc5da Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 30 Sep 2007 16:09:38 +0000 Subject: [PATCH] Indici e materiale sugli extended attributes. --- filedir.tex | 139 +++++++++++++++++++++++++++++++++------------------ prochand.tex | 32 ++++++------ 2 files changed, 107 insertions(+), 64 deletions(-) diff --git a/filedir.tex b/filedir.tex index a91b26f..ba1cd6b 100644 --- a/filedir.tex +++ b/filedir.tex @@ -2579,11 +2579,7 @@ l'atomicit In Linux gli attributi estesi sono sempre associati al singolo inode e l'accesso viene sempre eseguito in forma atomica, in lettura il valore corrente viene scritto su un buffer in memoria, mentre la scrittura prevede -che ogni valore precedente sia sovrascritto. L'accesso agli attributi estesi è -regolato dagli ordinari permessi dei file: occorre il permesso di lettura per -leggerli e quello di scrittura per scriverli o modificarli; il permesso di -esecuzione viene invece interpretato coma la capacità di ottenere la lista -degli attributi presenti. +che ogni valore precedente sia sovrascritto. Si tenga presente che non tutti i filesystem supportano gli \textit{Extended Attributes}, in particolare al momento della scrittura di queste dispense @@ -2591,53 +2587,96 @@ essi sono presenti solo su \textsl{ext2}, \textsl{ext3} e \textsl{XFS}. Inoltre a seconda della implementazione ci possono essere dei limiti sulla quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti - all'interno di un singolo blocco (pertanto con dimensioni massime - dell'ordine di 1024, 2048 o 4096 byte a seconda delle dimensioni di - quest'ultimo impostate in fase di formattazione), mentre con \textsl{XFS} - non ci sono limiti ed i dati vengono memorizzati in maniera diversa - (nell'inode stesso, in un blocco a parte, in una struttura ad albero - dedicata) per mantentere la scalabilità.} Infine lo spazio utilizzato per -mantenere gli attributi estesi viene tenuto in conto per il calcolo delle -quote di utente e gruppo proprietari del file. - -Come accennato gli \textit{Extended Attributes} costituiscono un meccanismo -per mantenere informazioni ulteriori associate al singolo file, che possono -avere gli usi più disparati.\footnote{come accennato sono usati per le ACL che - vedremo in sez.~\ref{sec:file_ACL}, ma anche per le estensioni di SELinux.} -Per poter distinguere i vari utilizzi possibili gli attributi sono stati -suddivisi in diverse \textsl{classi}, a cui poter applicare requisiti diversi -per l'accesso e la gestione. Per questo motivo il nome di un attributo deve -essere sempre specificato nella forma \texttt{namespace.attribute}, -\textit{namespace} fa riferimento alla classe a cui l'attributo appartiene; al -momento della scrittura di queste dispense essi sono definite le seguenti -classi: - - - - - - + all'interno di un singolo blocco (pertanto con dimensioni massime pari a + 1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate + in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono + limiti ed i dati vengono memorizzati in maniera diversa (nell'inode stesso, + in un blocco a parte, o in una struttura ad albero dedicata) per mantenerne + la scalabilità.} Infine lo spazio utilizzato per mantenere gli attributi +estesi viene tenuto in conto per il calcolo delle quote di utente e gruppo +proprietari del file. + +Come meccanismo per mantenere informazioni aggiuntive associate al singolo +file, gli \textit{Extended Attributes} possono avere usi anche molto diversi +fra loro. Per poterli distinguere allora sono stati suddivisi in +\textsl{classi}, a cui poter applicare requisiti diversi per l'accesso e la +gestione. Per questo motivo il nome di un attributo deve essere sempre +specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace} +fa riferimento alla classe a cui l'attributo appartiene, mentre +\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un +attributo esteso deve essere univoco. Al momento della scrittura di queste +dispense sono state definite le quattro classi di attributi riportate in +tab.~\ref{tab:extended_attribute_class}. \begin{table}[htb] \centering \footnotesize - \begin{tabular}{|c|l|} + \begin{tabular}{|c|p{10cm}|} \hline - \textbf{Nome} & \textbf{Classe} \\ + \textbf{Nome} & \textbf{Descrizione} \\ \hline \hline - \const{security}& . \\ - \const{system} & . \\ - \const{trusted} & . \\ - \const{user} & . \\ + \const{security}& Gli \textit{extended security attributes}: vengono + utilizzati dalle estensioni di sicurezza del kernel (i + \itindex{Linux~Security~Modules} \textit{Linux + Security Modules}), per le realizzazione di meccanismi + evoluti di controllo di accesso come \index{SELinux} + SELinux.\\ + \const{system} & Gli \textit{extended security attributes}: sono usati + dal kernel per memorizzare dati di sistema associati ai + file come le \itindex{Access~Control~List} ACL (vedi + sez.~\ref{sec:file_ACL}) o le \itindex{capabilities} + \textit{capabilities} (vedi + sez.~\ref{sec:proc_capabilities}).\\ + \const{trusted} & I \textit{irusted extended attributes}: visibili ed + accessibili soltanto a processi privilegiati. + Vengono utilizzati per poter realizzare in user space + meccanismi che consentano di mantenere delle + informazioni sui file che non siano accessibili ai + processi ordinari.\\ + \const{user} & Gli \textit{extended user attributes}: utilizzati per + mantenere informazioni aggiuntive sui file (come il + \textit{mime-type}, la codifica dei caratteri o del + file) accessibili dagli utenti.\\ \hline \end{tabular} \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le - varue classi di \textit{Extended Attributes}.} + varie classi di \textit{Extended Attributes}.} \label{tab:extended_attribute_class} \end{table} +Come accennato gli \textit{Extended Attributes} vengono utilizzati in forme +diverse ed in particolare anche per la realizzazione di estensioni del +meccanismo tradizionale dei controlli di accesso. Per questo motivo l'accesso +agli attributi estesi è revolato in maniera diversa a seconda della loro +classe; in particolare si hanno i seguenti casi: +\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}} +\item[\texttt{security}] l'accesso agli \textit{extended security attributes} + dipende dalle politiche di sicurezza stabilite da loro stessi tramite + l'utilizzo di un sistema di controllo basato sui + \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio + \index{SELinux} SELinux). Pertanto l'accesso in lettura o scruttura dipende + dalle politiche di sicurezza implementate all'interno dal modulo di + sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è + stato caricato nessun modulo di sicurezza l'accesso in lettura sarà + consentito a tutti i processi, mentre quello in scrittura solo ai processi + dotati della \index{capabilities} \textit{capability} + \const{CAP\_SYS\_ADMIN}. +\item[\texttt{system}] \textit{extended system attributes} +\item[\texttt{trusted}] \textit{trusted extended attributes} +\item[\texttt{user}] \textit{extended user attributes} +\end{basedescript} + + + è regolato dagli ordinari permessi dei file: occorre il +permesso di lettura per leggerli e quello di scrittura per scriverli o +modificarli; il permesso di esecuzione viene invece interpretato coma la +capacità di ottenere la lista degli attributi presenti. + + + + \itindend{Extended~Attributes} @@ -2645,7 +2684,7 @@ classi: % sistema è nei pacchetti libxattr1-dev e attr -\subsection{Le ACL} +\subsection{Le \textit{Access Control List}} \label{sec:file_ACL} @@ -2661,11 +2700,11 @@ complessa dei permessi di accesso.\footnote{gi Per questo motivo erano state progressivamente introdotte nelle varie versioni di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella -forma delle cosiddette \textit{Access Control List}. Nello sforzo di -standardizzare queste funzionalità era stato creato un gruppo di lavoro il cui -scopo era estendere lo standard POSIX 1003 attraverso due nuovi insiemi di -specifiche, la POSIX 1003.1e per l'interfaccia di programmazione e la POSIX -1003.2c per i comandi di shell. +forma delle cosiddette \textit{Access Control List} (indicate usualmente con +la sigla ACL). Nello sforzo di standardizzare queste funzionalità era stato +creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003 +attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia +di programmazione e la POSIX 1003.2c per i comandi di shell. Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di @@ -2676,11 +2715,12 @@ che nome di \textit{Posix ACL}. A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è -scelto di realizzare le ACL attraverso l'interfaccia degli \textit{Extended - Attributes}, e fornire tutte le relative funzioni di gestione tramite una -libreria, \texttt{libacl} che nasconde i dettagli implementativi delle stesse e -presenta ai programmi una interfaccia che fa riferimento allo standard POSIX -1003.1e. +scelto di realizzare le ACL attraverso l'uso degli +\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in +sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione +tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi +delle ACL e presenta ai programmi una interfaccia che fa riferimento allo +standard POSIX 1003.1e. @@ -2818,6 +2858,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: dell' effective passwd IGID locking swap saved text IRWXU IRWXG % LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail % LocalWords: FTP Di filter reiserfs Attributes Solaris Posix FreeBSD libacl +% LocalWords: XFS SELinux namespace attribute security trusted Draft %%% Local Variables: %%% mode: latex diff --git a/prochand.tex b/prochand.tex index fadcf97..d3e89f5 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1516,16 +1516,18 @@ Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in realtà già esistono estensioni di questo modello base, che lo rendono più flessibile e controllabile, come le \itindex{capabilities} \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL - per i file o il \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory - Access Control} di SELinux; inoltre basandosi sul lavoro effettuato con + per i file (vedi sez.~\ref{sec:file_ACL}) o il + \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control} + di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una - infrastruttura di sicurezza, il \textit{Linux Security Modules}, o LSM, in - grado di fornire diversi agganci a livello del kernel per modularizzare - tutti i possibili controlli di accesso.} di sicurezza di un sistema -unix-like è fondato sui concetti di utente e gruppo, e sulla separazione fra -l'amministratore (\textsl{root}, detto spesso anche \textit{superuser}) che -non è sottoposto a restrizioni, ed il resto degli utenti, per i quali invece -vengono effettuati i vari controlli di accesso. + infrastruttura di sicurezza, i \itindex{Linux~Security~Modules} + \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci + a livello del kernel per modularizzare tutti i possibili controlli di + accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di +utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root}, +detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed +il resto degli utenti, per i quali invece vengono effettuati i vari controlli +di accesso. Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per @@ -2109,12 +2111,12 @@ eseguibili,\footnote{una descrizione sommaria di questa funzionalit ma non essendo implementata non ne tratteremo qui.} in modo da poter stabilire quali capacità possono essere utilizzate quando viene messo in esecuzione uno specifico programma; attualmente però questa funzionalità non è -implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e - finora non è disponibile al momento neanche presente nessuna realizzazione - sperimentale delle specifiche POSIX.1e, anche se esistono dei patch di - sicurezza del kernel, come LIDS (vedi - \href{http://www.lids.org}{\texttt{http://www.lids.org/})} che realizzano - qualcosa di simile.} +implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; + benché l'infrastruttura per crearla sia presente (vedi anche + sez.~\ref{sec:file_xattr}) finora non è disponibile nessuna realizzazione + delle specifiche POSIX.1e, esistono però dei patch di sicurezza del kernel, + come LIDS (vedi \href{http://www.lids.org}{\texttt{http://www.lids.org/})} + che realizzano qualcosa di simile.} \begin{table}[!h!bt] -- 2.30.2