-%% filedir.tex
+4%% filedir.tex
%%
%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
file e directory, iniziando dalle funzioni di libreria che si usano per
copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
permette la manipolazione dei vari attributi di file e directory ed alla fine
-faremo una trattazione dettagliata su come è strutturato il sistema base di
-protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono
-la gestione. Tutto quello che riguarda invece la manipolazione del contenuto
-dei file è lasciato ai capitoli successivi.
+prenderemo in esame la struttura di base del sistema delle protezioni e del
+controllo dell'accesso ai file e le successive estensioni (\textit{Extended
+ Attributes}, ACL, quote disco, \textit{capabilities}). Tutto quello che
+riguarda invece la manipolazione del contenuto dei file è lasciato ai capitoli
+successivi.
\label{sec:file_link}
Una caratteristica comune a diversi sistemi operativi è quella di poter creare
-dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows o i
-nomi logici del VMS) che permettono di fare riferimento allo stesso file
+dei nomi fittizi (come gli alias del vecchio MacOS o i collegamenti di Windows
+o i nomi logici del VMS) che permettono di fare riferimento allo stesso file
chiamandolo con nomi diversi o accedendovi da directory diverse.
Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
\itindend{Access~Control~List}
+\subsection{La gestione delle quote disco}
+\label{sec:disk_quota}
+
+Quella delle quote disco è una funzionalità introdotta inizialmente da BSD, e
+presente in Linux fino dalla serie 2.0, che consente di porre dei tetti
+massimi al consumo delle risorse di un filesystem (spazio disco e
+\textit{inode}) da parte degli utenti e dei gruppi. Dato che la funzionalità
+ha senso solo per i filesystem su cui si mantengono i dati degli
+utenti\footnote{in genere la si attiva sul filesystem che contiene le
+ \textit{home} degli utenti, dato che non avrebbe senso per i file di sistema
+ che appartengono all'amministratore} essa deve essere abilitata
+esplicitamente, questo si fa tramite due distinte opzioni di montaggio,
+\texttt{usrquota} e \texttt{grpquota} che la attivano rispettivamente per gli
+utenti e per i gruppi, cosa che consente di abilitare solo quelle che
+interessano veramente.
+
+Il meccanismo prevede che per ciascun filesystem che supporta le quote (i vari
+\textit{extN}, \textit{btrfs}, \textit{XFS}, \textit{JFS}, \textit{ReiserFS})
+il kernel provveda a mantenere i dati relativi al consumo delle risorse in due
+file riservati,\footnote{la cosa vale per tutti i fileystem tranne
+ \textit{XFS} che mantiene i dati internamente; con la versione 2 del
+ supporto delle quote, l'unica rimasta in uso, questi file sono
+ \texttt{aquota.user} e \texttt{aquota.group} e si trovano nella directory
+ radice del filesytem su cui si sono attivate le quote.} e a
+
+
+% TODO trattare quote disco
+% vedi man quotactl
+
+
+
\subsection{La gestione delle \textit{capabilities}}
\label{sec:proc_capabilities}
si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
singoli file eseguibili, in modo da poter stabilire quali capacità possono
-essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità, chiamata \textit{file capabilities}, è
-stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva
-essere il programma stesso ad eseguire una riduzione esplicita delle sue
-capacità, cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la
-presenza di meccanismi alternativi per ottenere limitazioni delle capacità
-dell'amministratore a livello di sistema operativo, come \index{SELinux}
-SELinux.
+essere utilizzate quando viene messo in esecuzione uno specifico programma
+(una sorta di \acr{suid} anch'esso parcellizzato); ma il supporto per questa
+funzionalità, chiamata \textit{file capabilities}, è stato introdotto soltanto
+a partire dal kernel 2.6.24. Fino ad allora doveva essere il programma stesso
+ad eseguire una riduzione esplicita delle sue capacità, cosa che ha reso l'uso
+di questa funzionalità poco diffuso, vista la presenza di meccanismi
+alternativi per ottenere limitazioni delle capacità dell'amministratore a
+livello di sistema operativo, come \index{SELinux} SELinux.
Con questo supporto e con le ulteriori modifiche introdotte con il kernel
2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
sez.~\ref{sec:proc_setuid}; il loro significato, che è rimasto sostanzialmente
lo stesso anche dopo le modifiche seguite alla instroduzione delle
\textit{file capabilities} è il seguente:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
\item[\textit{permitted}] l'insieme delle \textit{capabilities}
``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
\textsl{può} impostare come \textsl{effettive} o come
\textsl{ereditabili}. Se un processo cancella una capacità da questo insieme
- non potrà più riassumerla.\footnote{questo è il comportamento più comune,
- che prevede però una serie di eccezioni, dipendenti anche dal tipo di
+ non potrà più riassumerla.\footnote{questo nei casi ordinari, sono
+ previste però una serie di eccezioni, dipendenti anche dal tipo di
supporto, che vedremo meglio in seguito dato il notevole intreccio nella
casistica.}
\item[\textit{inheritable}] l'insieme delle \textit{capabilities}
eseguita con l'uso di uno specifico attributo esteso,
\texttt{security.capability}, la cui modifica è riservata, (come illustrato
in sez.~\ref{sec:file_xattr}) ai processi dotato della capacità
- \macro{CAP\_SYS\_ADMIN}.} A differenza delle precedenti le \textit{file
- capabilities} hanno effetto soltanto quando il file che le porta viene
-eseguito come programma con una \func{exec}, e forniscono un meccanismo che
-consente l'esecuzione di alcuni programmi con maggiori privilegi, in sostanza
-una estensione dell'uso del \acr{suid} di root. Anche questi tre insiemi sono
-identicati con gli stessi nomi, ma il loro significato è:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+ \macro{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
+soltanto quando il file che le porta viene eseguito come programma con una
+\func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
+con maggiori privilegi; in sostanza sono una sorta di estensione dell'uso del
+\acr{suid} di root. Anche questi tre insiemi sono identicati con gli stessi
+nomi, ma il loro significato è diverso:
+\begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
\item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
- delle capacità che con l'esecuzione del file verranno comunque aggiunte alle
+ delle capacità che con l'esecuzione del programma verranno aggiunte alle
capacità \textsl{permesse} del processo.
\item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
- l'insieme delle capacità che con l'esecuzione del file possono essere
- ereditate dal processo originario (che cioè vengono tolte dalle
- \textsl{ereditabili} del processo originale all'esecuzione di
+ l'insieme delle capacità che con l'esecuzione del programma possono essere
+ ereditate dal processo originario (che cioè vengono tolte
+ dall'\textit{inheritable set} del processo originale all'esecuzione di
\func{exec}).
\item[\textit{effective}] in questo caso non si tratta di un insieme ma di un
unico valore logico; se attivo all'esecuzione del programma tutte le
capacità che risulterebbero \textsl{permesse} verranno pure attivate,
inserendole automaticamente nelle \textsl{effettive}, se disattivato nessuna
- capacità verrà attivata (cioè le effettive restano vuote).
+ capacità verrà attivata (cioè l'\textit{effective set} resta vuoto).
\end{basedescript}
-Infine come accennato, esiste un altro insieme, il
-\itindex{capabilities~bounding~set} \textit{capabilities bounding set}, il cui
-scopo è quello di costituire un limite alle capacità che possono essere
-attivate per un processo, ma il suo significato è stato completamente
-modificato con l'introduzione delle \textit{file capabilities}.
-
-
-a meno che non sia dotato della capacità
- \macro{CAP\_SETPCAP} nel qual caso potrà, come vedremo in seguito,
- impostarne anche altre.
-
-che non esegua un programma che è \acr{suid} di root o
- che ce l'ha nelle \textit{capabilities} presenti sul file
- eseguibile.\footnote{e neanche in questo caso se vengono usate le estensioni
- introdotte con il kernel 2.6.26 che vedremo più avanti.}
-
-Fino al kernel 2.6.25 oltre a questi tre insiemi, che sono relativi al singolo
-processo, il kernel manteneva un ulteriore insieme unico valido per tutto il
-sistema, chiamato \itindex{capabilities~bounding~set} \textit{capabilities
- bounding set}. Ogni volta che un programma viene posto in esecuzione con
-\func{exec} il contenuto degli insiemi \textit{effective} e \textit{permitted}
-venivano mascherati con un \textsl{AND} binario del contenuto corrente del
-\textit{capabilities bounding set}, così che il nuovo processo potesse
-disporre soltanto delle capacità in esso elencate.
-
-A lungo il \textit{capabilities bounding set} è stato un parametro generale di
-sistema, accessibile attraverso il contenuto del file
-\procfile{/proc/sys/kernel/cap-bound}, usato per impostare un limite
-universale alle capacità che possono essere accordate ai vari processi. Il
-suo valore poteva essere impostato esclusivamente dal primo processo eseguito
-nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo eseguito
-successivamente (cioè con \textsl{pid} diverso da 1) anche se eseguito con
-privilegi di amministratore, era in grado soltanto di rimuovere uno dei bit
-già presenti dell'insieme: questo significava che tolta una
-\textit{capability} dal \textit{capabilities bounding set} questa non era più
-disponibile, neanche per l'amministratore, a meno di un riavvio.
-
-Qualora invece si sia abilitato nel kernel il supporto per le
-\textit{capabilities} dei file il \textit{capabilities bounding set} mantiene
-il suo significato di limite alle capacità che possono essere assegnate al
-processo, ma diventa una proprietà dello stesso (un quarto insieme che il
-processo si porta dietro). In questo
-
-
-
- viene a costituire un doppio limite:
-
-
+\itindbeg{capabilities~bounding~set}
+
+Infine come accennato, esiste un ulteriore insieme, chiamato
+\textit{capabilities bounding set}, il cui scopo è quello di costituire un
+limite alle capacità che possono essere attivate per un programma. Il suo
+funzionamento però è stato notevolmente modificato con l'introduzione delle
+\textit{file capabilities} e si deve pertanto prendere in considerazione una
+casistica assai complessa.
+
+Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
+\textit{file capabilities}, il \textit{capabilities bounding set} è un
+parametro generale di sistema, il cui valore viene riportato nel file
+\procfile{/proc/sys/kernel/cap-bound}. Il suo valore iniziale è definito in
+sede di compilazione del kernel, e da sempre ha previsto come default la
+presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In
+questa situazione solo il primo processo eseguito nel sistema (quello con
+\textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di
+modificarlo, ogni processo eseguito successivamente, anche se eseguito con
+privilegi di amministratore,\footnote{per essere precisi occorreva la capacità
+ \const{CAP\_SYS\_MODULE}.} è in grado soltanto di rimuovere una delle
+\textit{capabilities} già presenti dell'insieme.
+
+In questo caso l'effetto del \textit{capabilities bounding set} è che solo le
+capacità in esso presenti possono essere trasmesse ad un altro programma
+attraverso una \func{exec}. Questo in sostanza significa che se si elimina da
+esso una capacità, considerato che \texttt{init} (almeno nelle versioni
+ordinarie) non supporta la reimpostazione del \textit{bounding set}, questa
+non sarà più disponibile per nessun processo a meno di un riavvio, eliminando
+così in forma definitiva quella capacità per tutti, compreso
+l'amministratore.\footnote{la qual cosa, visto il default usato per il
+ \textit{capabilities bounding set}, significa anche che \const{CAP\_SETPCAP}
+ non è stata praticamente mai usata nella sua forma orginale.}
+
+Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
+è diventato una proprietà di ciascun processo, che viene propagata invariata
+sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
+\procfile{/proc/sys/kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
+presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
+
+Con questo nuovo meccanismo il \textit{bounding set} continua a ricoprire un
+ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
+limite alle capacità che possono essere aggiunte al processo in quanto
+presenti nel \textit{permitted set} del programma messo in esecuzione, in
+sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
+suo \textit{permitted set} solo se questa è anche nel \textit{bounding
+ set}. In questo modo si possono rimuovere definitivamente certe capacità da
+un processo, anche qualora questo dovesse eseguire un programma
+privilegiato.
+
+Si tenga presente però che in questo caso il \textit{bounding set} blocca
+esclusivamente le capacità indicate nel \textit{permitted set} del programma
+che verrebbero attivate in caso di esecuzione, non quelle eventualmente già
+presenti nell'\textit{inheritable set} del processo (ad esempio perché
+presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
+eseguendo un programma che abbia anche lui dette capacità nel suo
+\textit{inheritable set} queste verrebbero assegnate.
+
+In questa seconda versione inoltre il \textit{bounding set} costituisce anche
+un limite per le capacità che possono essere aggiunte all'\textit{inheritable
+ set} del processo con \func{capset}, sempre nel senso che queste devono
+essere presenti nel \textit{bounding set} oltre che nel \textit{permitted set}
+del processo.
+\itindend{capabilities~bounding~set}
+Come si può notare per fare ricorso alle \textit{capabilities} occorre
+comunque farsi carico di una notevole complessità di gestione, aggravata dalla
+presenza di una radicale modifica del loro funzionamento con l'introduzione
+delle \textit{file capabilities}. Considerato che il meccanismo originale era
+incompleto e decisamente problematico nel caso di programmi che non ne
+sappiano tener conto,\footnote{si ebbe un grosso problema di sicurezza con
+ \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
+ dall'\textit{inheritable set} si ottenne di far fallire una \func{setuid},
+ in maniera inaspettata per il programma (che aspettandosi il successo della
+ funzione non ne controllava lo stato di uscita) con la conseguenza di
+ effettuare come amministratore operazioni che altrimenti sarebbero state
+ eseguite, senza poter apportare danni, da utente normale.} ci soffermeremo
+solo sulla implementazione completa presente a partire dal kernel 2.6.25,
+tralasciando ulteriori dettagli riguardo la versione precedente.
+
Quando un programma viene messo in esecuzione\footnote{cioè quando viene
molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
che è opportuno dettagliare maggiormente.
-\begin{table}[!h!bt]
+\begin{table}[!h!btp]
\centering
\footnotesize
- \begin{tabular}{|l|p{11.5cm}|}
+ \begin{tabular}{|l|p{11.9cm}|}
\hline
\textbf{Capacità}&\textbf{Descrizione}\\
\hline
\itindex{multicast} \textit{multicast}.\\
\const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
\texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
- \const{CAP\_SETPCAP} & Prima del 2.6.24 la capacità di impostare o
- rimuovere le \textit{capabilities} da un
- processo, dopo quella di impostare una capacità
- del \textit{bounding set} nelle proprie
- \textit{inheritable} o rimoverla dal
- \textit{bounding set} stesso.\\
+ \const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle
+ \textit{capabilities}.\\
\const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
amministrativi. \\
\const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
\const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
\textit{accounting} dei processi (vedi
sez.~\ref{sec:sys_bsd_accounting}).\\
- \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
\func{ptrace} (vedi
sez.~\ref{sec:xxx_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
+ \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
di I/O con \func{ioperm} e \func{iopl} (vedi
sez.~\ref{sec:file_io_port}).\\
\const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
\textit{Discrectionary Access Control} (da cui il nome DAC).}
-La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
-rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
-in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
- l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
- vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
-queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi
+
+Prima di dettagliare il significato della capacità più generiche, conviene
+però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
+stato completamente cambiato con l'introduzione delle \textit{file
+ capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
+che permetteva al processo che la possedeva di impostare o rimuovere le
+\textit{capabilities} che fossero presenti nel \textit{permitted set} del
+chiamante di un qualunque altro processo. In realtà questo non è mai stato
+l'uso inteso nelle bozze dallo standard POSIX, ed inoltre, come si è già
+accennato, dato che questa capacità è assente nel \textit{capabilities
+ bounding set} usato di default, essa non è neanche mai stata realmente
+disponibile.
+
+Con l'introduzione \textit{file capabilities} e il cambiamento del significato
+del \textit{capabilities bounding set} la possibilità di modificare le
+capacità di altri processi è stata completamente rimossa, e
+\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
+significato originario, e cioè la capacità del processo di poter inserire nel
+suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
+ set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
+processo di eliminare una capacità dal proprio \textit{bounding set} (con la
+conseguente impossibilità successiva di eseguire programmi con quella
+capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
+
+La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
+maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
+processo che non ha la proprietà di un file in un vasto campo di
+operazioni;\footnote{vale a dire la richiesta che l'user-ID effettivo del
+ processo (o meglio il \textit{filesystem user-ID}, vedi
+ sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste
+comprendono i cambiamenti dei permessi e dei tempi del file (vedi
sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
impostazioni degli attributi estesi e delle ACL (vedi
sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
+Questo modo di intendere ... da fare ... per cui
+a partire dal 2.6.24/5 è divenuta quella di impostare una capacità del
+\textit{bounding set} nelle proprie \textit{inheritable} o rimoverla dal
+\textit{bounding set} stesso.
Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
funzioni che permettono rispettivamente di leggere ed impostare i valori dei
projects / gapil.git / commitdiff