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
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}
% sistema è nei pacchetti libxattr1-dev e attr
-\subsection{Le ACL}
+\subsection{Le \textit{Access Control List}}
\label{sec:file_ACL}
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
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.
% 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
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
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]
projects / gapil.git / commitdiff