+\subsection{La gestione delle \textit{capabilities}}
+\label{sec:proc_capabilities}
+
+\itindbeg{capabilities}
+
+Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
+gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
+fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
+quando si siano predisposte delle misure di protezione per in essere in grado
+di difendersi dagli effetti di una eventuale compromissione del
+sistema,\footnote{come montare un filesystem in sola lettura per impedirne
+ modifiche, o marcare un file come immutabile.} una volta che questa sia
+stata effettuata e si siano ottenuti i privilegi di amministratore, queste
+potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
+ nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+ la marcatura di immutabilità.}
+
+Il problema consiste nel fatto che nell'architettura tradizionale di un
+sistema unix-like i controlli di accesso sono basati su un solo livello di
+separazione: per i processi normali essi sono posti in atto, mentre per i
+processi con i privilegi di amministratore essi non vengono neppure eseguiti;
+per questo motivo non era previsto alcun modo per evitare che un processo con
+diritti di amministratore non potesse eseguire certe operazioni, o per cedere
+definitivamente alcuni privilegi da un certo momento in poi.
+
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
+suddividere i vari privilegi tradizionalmente associati all'amministratore in
+un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
+potessero essere abilitate e disabilitate in maniera indipendente per ciascun
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
+situazione di ``\textsl{tutto o nulla}''.
+
+Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
+ 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à è 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 come
+\index{SELinux} SELinux.
+
+Per gestire questo meccanismo ciascun processo porta con sé tre distinti
+insiemi di \textit{capabilities}, che vengono denominati rispettivamente
+\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
+vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
+ li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid},
+ all'interno della \struct{task\_struct} di ciascun processo (vedi
+ fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
+ \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
+ \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+ il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
+ciascun bit corrisponde ad una capacità diversa.
+
+L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
+per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
+sono mantenuti i diversi insiemi di identificatori di
+sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{effective}] l'insieme delle \textit{capabilities}
+ ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+ kernel quando deve eseguire il controllo di accesso per le varie operazioni
+ compiute dal processo.
+\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}. Se un processo cancella una
+ capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+ un programma che è \acr{suid} di root).
+\item[\textit{inherited}] l'insieme delle \textit{capabilities}
+ ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+ programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
+ del caso che questo sia \acr{suid} di root).
+\label{sec:capabilities_set}
+\end{basedescript}
+
+Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
+mantiene un insieme generale 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} vengono mascherati con
+un \textsl{AND} binario del contenuto corrente del \textit{capabilities
+ bounding set}, così che il nuovo processo potrà disporre soltanto delle
+capacità in esso elencate.
+
+Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
+attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
+questa sua caratteristica consente di impostare un limite generale alle
+capacità che possono essere accordate ai vari processi. Questo valore può
+essere impostato ad un valore arbitrario 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 potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+disponibile, neanche per l'amministratore, a meno di un riavvio.
+
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+ eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
+ \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
+(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
+le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
+non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
+eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
+ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
+ bounding set}. In questo modo si può far si che ad un processo eseguito in
+un secondo tempo possano essere trasmesse solo un insieme limitato di
+capacità, impedendogli di recuperare quelle assenti nell'insieme
+\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
+vengono mantenute le stesse capacità del processo padre.
+
+
+% TODO verificare per process capability bounding set, vedi:
+% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+
+% TODO capire cosa cambia con i patch vari, vedi
+% http://lwn.net/Articles/280279/
+% http://lwn.net/Articles/256519/
+% http://lwn.net/Articles/211883/
+
+
+Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
+breve descrizione ed il nome delle costanti che le identificano, è riportato
+in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
+ tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
+ capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
+ aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
+riporta le \textit{capabilities} previste anche nella bozza dello standard
+POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
+tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
+molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
+che è opportuno dettagliare maggiormente.
+
+\begin{table}[!h!bt]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{11.5cm}|}
+ \hline
+ \textbf{Capacità}&\textbf{Descrizione}\\
+ \hline
+ \hline
+%
+% POSIX-draft defined capabilities.
+%
+ \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+ auditing del kernel (dal kernel 2.6.11).\\
+ \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+ controllo dell'auditing (dal kernel 2.6.11).\\
+ % TODO verificare questa roba dell'auditing
+ \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
+ proprietario di un file (vedi
+ sez.~\ref{sec:file_ownership_management}).\\
+ \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+ permessi di lettura, scrittura ed esecuzione dei
+ file,\footnotemark (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+ permessi di lettura ed esecuzione per
+ le directory (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_FOWNER} & La capacità di evitare il controllo della
+ proprietà di un file per tutte
+ le operazioni privilegiate non coperte dalle
+ precedenti \const{CAP\_DAC\_OVERRIDE} e
+ \const{CAP\_DAC\_READ\_SEARCH}.\\
+ \const{CAP\_FSETID} & La capacità di evitare la cancellazione
+ automatica dei bit \itindex{suid~bit} \acr{suid}
+ e \itindex{sgid~bit} \acr{sgid} quando un file
+ per i quali sono impostati viene modificato da
+ un processo senza questa capacità e la capacità
+ di impostare il bit \acr{sgid} su un file anche
+ quando questo è relativo ad un gruppo cui non si
+ appartiene (vedi
+ sez.~\ref{sec:file_perm_management}).\\
+ \const{CAP\_SETFCAP} & La capacità di impostare le
+ \textit{capabilities} di un file (dal kernel
+ 2.6.24).\\
+ \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
+ processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
+ \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
+ processi, sia il principale che i supplementari,
+ (vedi sez.~\ref{sec:proc_setgroups}) che quelli
+ trasmessi tramite i socket \textit{unix domain}
+ (vedi sez.~\ref{sec:unix_socket}).\\
+ \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
+ processo (vedi sez.~\ref{sec:proc_setuid}) e di
+ trasmettere un user ID arbitrario nel passaggio
+ delle credenziali coi socket \textit{unix
+ domain} (vedi sez.~\ref{sec:unix_socket}).\\
+%
+% Linux specific capabilities
+%
+\hline
+ \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
+ locking} \itindex{memory~locking} con le
+ funzioni \func{mlock}, \func{mlockall},
+ \func{shmctl}, \func{mmap} (vedi
+ sez.~\ref{sec:proc_mem_lock} e
+ sez.~\ref{sec:file_memory_map}). \\
+ \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+ per le operazioni sugli oggetti di
+ intercomunicazione fra processi (vedi
+ sez.~\ref{sec:ipc_sysv}).\\
+ \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
+ \index{file!lease} (vedi
+ sez.~\ref{sec:file_asyncronous_lease})
+ pur non essendo proprietari del file (dal kernel
+ 2.4).\\
+ \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+ attributi \textit{immutable} e
+ \itindex{append~mode} \textit{append only} (se
+ supportati).\\
+ \const{CAP\_MKNOD} & La capacità di creare
+ \index{file!di~dispositivo} file di dispositivo
+ con \func{mknod} (vedi
+ sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
+ \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+ privilegiate sulla rete.\\
+ \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+ su porte riservate (vedi
+ sez.~\ref{sec:TCP_func_bind}).\\
+ \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+ \itindex{broadcast} \textit{broadcast} e
+ \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} & La capacità di impostare o rimuovere una
+ capacità.\\
+ % TODO cambiata nel 2.4.24 rc1 ?
+ \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
+ sistema.\\
+% TODO trattare reboot e kexec
+ \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+ \func{chroot} (vedi
+ sez.~\ref{sec:file_chroot}).\\
+ \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
+ kernel 2.6.25).\\
+ \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
+ kernel 2.6.25).\\
+ \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+ kernel. \\
+ \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei
+ processi. \\
+ \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
+ \func{ptrace} (vedi
+ sez.~\ref{sec:xxx_ptrace}).\\
+ \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni 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 limitazioni sulle
+ risorse.\\
+ \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ (vedi sez.~\ref{sec:sys_time}).\\
+ \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ della console, con la funzione
+ \func{vhangup}.\\
+ \const{CAP\_SYSLOG} & La capacità di gestire il buffer dei messaggi
+ del kernel, (vedi sez.~\ref{sec:sess_daemon}),
+ introdotta dal kernel 2.6.38 come capacità
+ separata da \const{CAP\_SYS\_ADMIN}.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano le \textit{capabilities} presenti nel
+ kernel.}
+\label{tab:proc_capabilities}
+\end{table}
+
+\footnotetext{vale a dire i permessi caratteristici del modello classico del
+ 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
+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
+\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
+sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
+\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
+sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
+
+Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
+la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
+privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
+il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
+interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
+tabella di instradamento.
+
+Una terza \textit{capability} con vasto campo di applicazione è
+\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
+come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
+disattivare la swap, montare, rimontare e smontare filesystem (vedi
+sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
+oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
+attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
+sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
+trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
+assegnare classi privilegiate per lo scheduling dell'I/O (vedi
+sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
+di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
+effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
+sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
+sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
+(vedi sez.~\ref{sec:process_clone}).
+
+Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
+aumentare le priorità di esecuzione dei processi, come la diminuzione del
+valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
+priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
+l'impostazione delle affinità di processore (vedi
+sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
+anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
+alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
+arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
+politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
+
+Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
+possibilità di superare i limiti imposti sulle risorse di sistema, come usare
+lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
+usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
+filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
+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}).
+
+
+Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
+funzioni che permettono rispettivamente di leggere ed impostare i valori dei
+tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
+e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
+loro rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/capability.h}