+\subsection{La gestione del \textit{Secure Computing}.}
+\label{sec:procadv_seccomp}
+
+\itindbeg{secure~computing~mode}
+
+Il \textit{secure computing mode} è un meccanismo ideato per fornire un
+supporto per l'esecuzione di codice esterno non fidato e non verificabile a
+scopo di calcolo. L'idea era quella di disporre di una modalità di esecuzione
+dei programmi che permettesse di vendere la capacità di calcolo della propria
+macchina ad un qualche servizio di calcolo distribuito, senza comprometterne
+la sicurezza eseguendo codice non sotto il proprio controllo.
+
+La prima versione del meccanismo è stata introdotta con il kernel
+2.6.23,\footnote{e disponibile solo avendo abilitato il supporto nel kernel
+ con l'opzione di configurazione \texttt{CONFIG\_SECCOMP}.} è molto semplice,
+il \textit{secure computing mode} viene attivato con \func{prctl} usando
+l'opzione \const{PR\_SET\_SECCOMP}, ed indicando \const{SECCOMP\_MODE\_STRICT}
+come valore per \param{arg2} (all'epoca unico valore possibile). Una volta
+abilitato in questa modalità (in seguito denominata \textit{strict mode}) il
+processo o il \textit{thread} chiamante potrà utilizzare soltanto un insieme
+estremamente limitato di \textit{system call}: \func{read}, \func{write},
+\func{\_exit} e \funcm{sigreturn}; l'esecuzione di qualsiasi altra
+\textit{system call} comporta l'emissione di un \signal{SIGKILL} e conseguente
+terminazione immediata del processo.
+
+Si tenga presente che in questo caso, con versioni recenti della \acr{glibc}
+(il comportamento è stato introdotto con la 2.3), diventa impossibile usare
+anche \func{\_exit} in \textit{strict mode}, in quanto questa funzione viene
+intercettata ed al suo posto viene chiamata \func{exit\_group} (vedi
+sez.~\ref{sec:pthread_management}) che non è consentita e comporta un
+\signal{SIGKILL}.
+
+Si tenga presente che, non essendo \func{execve} fra le funzioni permesse, per
+poter eseguire un programma terzo essendo in \textit{strict mode} questo dovrà
+essere fornito in una forma di codice interpretabile fornito attraverso un
+socket o una \textit{pipe}, creati prima di lanciare il processo che eseguirà
+il codice non fidato.
+
+
+
+% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
+% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
+% Documentation/prctl/seccomp_filter.txt
+% vedi anche http://lwn.net/Articles/600250/
+
+% TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
+% * Documentation/prctl/seccomp_filter.txt
+% * http://lwn.net/Articles/475043/
+
+% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
+% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
+
+
+\itindend{secure~computing~mode}
+
+\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/)
+
projects / gapil.git / blobdiff