+\subsection{Altre funzionalità di sicurezza.}
+\label{sec:procadv_security_misc}
+
+Oltre alle funzionalità specifiche esaminate nelle sezioni precedenti, il
+kernel supporta una varietà di ulteriori impostazioni di sicurezza,
+accessibili nelle maniere più varie, che abbiamo raccolto in questa sezione.
+
+Una serie di modalità di sicurezza sono attivabili a richiesta attraverso
+alcune opzioni di controllo attivabili via \func{sysctl} o il filesystem
+\texttt{/proc}, un elenco delle stesse e dei loro effetti è il seguente:
+
+\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
+\item[\sysctlrelfiled{fs}{protected\_hardlinks}] Un valore nullo, il default,
+ mantiene il comportamento standard che non pone restrizioni alla creazione
+ di \textit{hard link}. Se il valore viene posto ad 1 vengono invece attivate
+ una serie di restrizioni protettive, denominate
+ \itindex{protected~hardlinks} \textit{protected hardlinks}, che se non
+ soddisfatte causano il fallimento di \func{link} con un errore di
+ \errval{EPERM}. Perché questo non avvenga almeno una delle seguenti
+ condizioni deve essere soddisfatta:
+ \begin{itemize*}
+ \item il chiamante deve avere privilegi amministrativi (la
+ \textit{capability} \const{CAP\_FOWNER}). In caso di utilizzo
+ dell'\textit{user namespace} oltre a possedere \const{CAP\_FOWNER} è
+ necessario che l'\ids{UID} del proprietario del file sia mappato nel
+ \textit{namespace}.
+ \item il \textit{filesystem} \ids{UID} del chiamante (normalmente
+ equivalente all'\ids{UID} effettivo) deve corrispondere a quello del
+ proprietario del file a cui si vuole effettuare il collegamento.
+ \item devono essere soddisfatte tutte le seguenti condizioni:
+ \begin{itemize*}
+ \item il file è un file ordinario
+ \item il file non ha il \acr{suid} bit attivo
+ \item il file non ha lo \acr{sgid} bit attivo ed il permesso di esecuzione
+ per il gruppo
+ \item il chiamante ha i permessi di lettura e scrittura sul file
+ \end{itemize*}
+ \end{itemize*}
+
+ In sostanza in questo caso un utente potrà creare un collegamento diretto ad
+ un altro file solo se ne è il proprietario o se questo è un file ordinario
+ senza permessi speciali ed a cui ha accesso in lettura e scrittura.
+
+ Questa funzionalità fornisce una protezione generica che non inficia l'uso
+ ordinario di \func{link}, ma rende impraticabili una serie di possibili
+ abusi della stessa; oltre ad impedire l'uso di un \textit{hard link} come
+ variante in un attacco di \textit{symlink race} (eludendo i
+ \textit{protected symlinks} di cui al punto successivo), evita anche che si
+ possa lasciare un riferimento ad un eventuale programma \acr{suid}
+ vulnerabile, creando un collegamento diretto allo stesso.
+
+
+\item[\sysctlrelfiled{fs}{protected\_symlinks}] Un valore nullo, il default,
+ mantiene il comportamento standard che non pone restrizioni nel seguire i
+ link simbolici. Se il valore viene posto ad 1 vengono attivate delle
+ restrizioni protettive, denominate \itindex{protected~symlinks}
+ \textit{protected symlinks}. Quando vengono attivate una qualunque funzione
+ che esegua la risoluzione di un \textit{pathname} contenente un link
+ simbolico non conforme alle restrizioni fallirà con un errore di
+ \errval{EACCESS}. Per evitare l'errore deve essere soddisfatta una delle
+ seguenti condizioni:
+ \begin{itemize*}
+ \item il link non è in una directory con permessi analoghi a \file{/tmp}
+ (scrivibile a tutti e con lo \textit{sticky bit} attivo);
+ \item il link è in una directory con permessi analoghi a \file{/tmp} ma è
+ soddisfatta una delle condizioni seguenti:
+ \begin{itemize*}
+ \item il link simbolico appartiene al chiamante: il controllo viene fatto
+ usando il \textit{filesystem} \ids{UID} (che normalmente corrisponde
+ all'\ids{UID} effettivo).
+ \item il link simbolico ha lo stesso proprietario della directory.
+ \end{itemize*}
+ \end{itemize*}
+
+ Questa funzionalità consente di rendere impraticabili alcuni attacchi in cui
+ si approfitta di una differenza di tempo fra il controllo e l'uso di un
+ file, ed in particolare quella classe di attacchi viene usualmente chiamati
+ \textit{symlink attack},\footnote{si tratta di un sottoinsieme di quella
+ classe di attacchi chiamata genericamente \textit{TOCTTOU}, acronimo
+ appunto di \textit{Time of check to time of use}.} di cui abbiamo parlato
+ in sez.~\ref{sec:file_temp_file}.
+
+ Un possibile esempio di questo tipo di attacco è quello contro un programma
+ che viene eseguito per conto di un utente privilegiato (ad esempio un
+ programma con il \acr{suid} o lo \acr{sgid} bit attivi) che prima controlla
+ l'esistenza di un file e se non esiste lo crea. Se questa procedura, che è
+ tipica della creazione di file temporanei sotto \file{/tmp}, non viene
+ eseguita in maniera corretta,\footnote{ad esempio con le modalità che
+ abbiamo trattato in sez.~\ref{sec:file_temp_file}, che per quanto note da
+ tempo continuano ad essere ignorate.} un attaccante ha una finestra di
+ tempo in cui può creare prima del programma un \textit{link simbolico} ad un
+ file di sua scelta, compresi file di dispositivo o file a cui non avrebbe
+ accesso, facendolo poi utilizzare al programma.
+
+ Attivando la funzionalità si rende impossibile seguire un link simbolico in
+ una directory temporanea come \texttt{/tmp}, a meno che questo non sia di
+ proprietà del chiamante, o che questo non appartenga al proprietario della
+ directory. Questo impedisce che i link simbolici creati da un attaccante
+ possano essere seguiti da un programma privilegiato (perché apparterranno
+ all'attaccante) mentre quelli creati dall'amministratore (che i genere è il
+ proprietario di \texttt{/tmp}) saranno seguiti comunque.
+
+\end{basedescript}
+
+
+% TODO: trattare pure protected_regular e protected_fifos introdotti con il
+% 4.19 (vedi https://lwn.net/Articles/763106/)
+
+
+
+% TODO: trattare keyctl (man 2 keyctl)
+% (fare sezione dedicata ????)
+% TODO documentare la Crypto API del kernel
+
+
+% TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
+% pkey_mprotect, introdotte con il kernel 4.8, vedi
+% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
+
+% TODO documentare la syscall getrandom, introdotta con il kernel 3.17, vedi
+% http://lwn.net/Articles/606141/, ed introdotta con le glibc solo con la
+% versione 2.25 con getentropy, vedi https://lwn.net/Articles/711013/ ed i
+% problemi successivi vedi https://lwn.net/Articles/800509/
+
+%\subsection{La gestione delle chiavi crittografiche}
+%\label{sec:keyctl_management}
+
+% TODO non è chiaro se farlo qui, ma documentare la syscall bpf aggiunta con il
+% kernel 3.18, vedi http://lwn.net/Articles/612878/; al riguardo vedi anche
+% https://lwn.net/Articles/660331/
+
+
+\section{Funzioni di gestione e controllo}
+\label{sec:proc_manage_control}
+
+In questa sezione prenderemo in esame alcune specifiche \textit{system call}
+dedicate al controllo dei processi sia per quanto riguarda l'impostazione di
+caratteristiche specialistiche, che per quanto riguarda l'analisi ed il
+controllo della loro esecuzione.
+
+\subsection{La funzione \func{prctl}}
+\label{sec:process_prctl}
+
+Benché la gestione ordinaria dei processi possa essere effettuata attraverso
+le funzioni che abbiamo già esaminato nei capitoli \ref{cha:process_interface}
+e \ref{cha:process_handling}, esistono una serie di proprietà e
+caratteristiche specifiche dei processi per la cui gestione è stata
+predisposta una apposita \textit{system call} che fornisce una interfaccia
+generica per tutte le operazioni specialistiche. La funzione di sistema è
+\funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è standardizzata
+ ed è specifica di Linux, anche se ne esiste una analoga in IRIX; è stata
+ introdotta con il kernel 2.1.57.}
+
+\begin{funcproto}{
+\fhead{sys/prctl.h}
+\fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned
+ long arg4, \\
+\phantom{int prctl(}unsigned long arg5)}
+\fdesc{Esegue una operazione speciale sul processo corrente.}