Correzioni varie e trattazione shared subtree, aggiornamento di mount,
[gapil.git] / procadv.tex
index 98d403122e43dbf09d50c15aeb257fee4481283c..27cf9dc24ba5ff457c051f8e5d7fcd61a3088e97 100644 (file)
@@ -223,44 +223,29 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
   scopo di queste dispense, per i dettagli si consulti la documentazione su
   \textit{Yama} nei sorgenti del kernel. Introdotta a partire dal kernel 3.4.
 
-\itindbeg{secure~computing~mode}
-\item[\constd{PR\_SET\_SECCOMP}] Imposta il cosiddetto \textit{secure computing
-    mode} per il processo corrente. Prevede come unica possibilità
-  che \param{arg2} sia impostato ad 1. Una volta abilitato il \textit{secure
-    computing mode} il processo potrà utilizzare soltanto un insieme
-  estremamente limitato di \textit{system call}: \func{read}, \func{write},
-  \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system call} porterà
-  all'emissione di un \signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}).
-  Il \textit{secure computing mode} è stato ideato per fornire un supporto per
-  l'esecuzione di codice esterno non fidato e non verificabile a scopo di
-  calcolo;\footnote{lo scopo è quello di poter vendere la capacità di calcolo
-    della proprio macchina ad un qualche servizio di calcolo distribuito senza
-    comprometterne la sicurezza eseguendo codice non sotto il proprio
-    controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
-  una \textit{pipe}, e per evitare problemi di sicurezza non sono possibili
-  altre operazioni se non quelle citate.  Introdotta a partire dal kernel
-  2.6.23, disponibile solo se si è abilitato il supporto nel kernel con
-  \texttt{CONFIG\_SECCOMP}.
-
-% 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/
+\item[\constd{PR\_SET\_SECCOMP}] Attiva il \textit{secure computing mode} per
+  il processo corrente. Introdotta a partire dal kernel 2.6.23 la funzionalità
+  è stata ulteriorimente estesa con il kernel 3.5, salvo poi diventare un
+  sottoinsieme della \textit{system call} \func{seccomp} a partire dal kernel
+  3.17. Prevede che si indichi per \param{arg2} il valore
+  \const{SECCOMP\_MODE\_STRICT} (unico possibile fino al kernel 2.6.23) per
+  selezionare il cosidetto \textit{strict mode} o, dal kernel 3.5,
+  \const{SECCOMP\_MODE\_FILTER} per usare il \textit{filter mode}. Tratteremo
+  questa opzione nei dettagli più avanti, in sez.~\ref{sec:procadv_seccomp},
+  quando affronteremo l'argomento del \textit{Secure Computing}.
 
 \item[\constd{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
-  lo stato corrente del \textit{secure computing mode}, al momento attuale la
-  funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
-  che la chiamata di questa funzione in \textit{secure computing mode}
-  comporterebbe l'emissione di \signal{SIGKILL}, è stata comunque definita per
-  eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
-\itindend{secure~computing~mode}
+  lo stato corrente del \textit{secure computing mode}. Fino al kernel 3.5,
+  quando era possibile solo lo \textit{strict mode}, la funzione era
+  totalmente inutile in quanto l'unico valore ottenibile era 0 in assenza di
+  \textit{secure computing}, dato che la chiamata di questa funzione in
+  \textit{strict mode} avrebbe comportato l'emissione di \signal{SIGKILL} per
+  il chiamante. La funzione però, a partire dal kernel 2.6.23, era stata
+  comunque definita per eventuali estensioni future, ed infatti con
+  l'introduzione del \textit{filter mode} con il kernel 3.5, se essa viene
+  inclusa nelle funzioni consentite restituisce il valore 2 quando il
+  \textit{secure computing mode} è attivo (se non inclusa si avrà di nuovo un
+  \signal{SIGKILL}).
 
 \item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
   processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
@@ -296,8 +281,8 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
   generazione di un segnale di \signal{SIGSEGV} (vedi
   sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
   disabilitata se si attiva il \textit{secure computing mode} (vedi
-  \const{PR\_SET\_SECCOMP}).  Introdotta a partire dal kernel
-  2.6.26, solo su x86.
+  \const{PR\_SET\_SECCOMP} e sez.~\ref{sec:procadv_seccomp}).  Introdotta a
+  partire dal kernel 2.6.26, solo su x86.
 
 \item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
   lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
@@ -606,10 +591,10 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa
   informazioni, che saranno così indipendenti per i due processi, come avviene
   nel comportamento ordinario di un sistema unix-like.
 
-\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo
-  processo condividerà con il padre il contesto dell'I/O, altrimenti, come
-  come avviene nel comportamento ordinario con una \func{fork} otterrà un suo
-  contesto dell'I/O. 
+\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo processo
+  condividerà con il padre il contesto dell'I/O, altrimenti, come avviene nel
+  comportamento ordinario con una \func{fork} otterrà un suo contesto
+  dell'I/O.
 
   Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
   sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
@@ -716,9 +701,11 @@ degli altri gruppi, che costituisce poi quello che viene chiamato un
 \label{sec:process_security}
 
 Tratteremo in questa sezione le funzionalità più avanzate relative alla
-gestione della sicurezza, a partire dalle \textit{capabilities} e dalle
-funzionalità di \textit{Secure Computing}, fino alle funzionalità relative
-alla gestione delle chiavi crittografiche.
+gestione della sicurezza ed il controllo degli accessi all'interno dei
+processi, a partire dalle \textit{capabilities} e dalle funzionalità di
+\textit{Secure Computing}. Esamineremo inoltre tutte le altre funzionalità
+relative alla sicurezza come gestione delle chiavi crittografiche e varie
+estensioni e funzionalita disponibili su questo argomento.
 
 
 
@@ -999,7 +986,7 @@ riesce così a riottenere il comportamento classico di un sistema unix-like.
 Una seconda circostanza è quella relativa a cosa succede alle
 \textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
 nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
-cedere o riottenere i privilegi di amministratore) che si possono effettuare
+cedere o riottenere i privilegi di amministratore) che si possono effettuare
 con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
 casistica è di nuovo alquanto complessa, considerata anche la presenza dei
 diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
@@ -1129,15 +1116,14 @@ operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}.
 % 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{include/linux/capabilities.h}, è aggiornato al kernel 3.2.} 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
+Un elenco 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{include/linux/capabilities.h}, è aggiornato
+  al kernel 3.2.} 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.
@@ -2020,10 +2006,94 @@ funzione.
 
 
 
+\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 quello di poter 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.
+
+Nella prima versione del meccanismo, introdotto con il kernel 2.6.23 e
+disponibile solo avendo è abilitato il supporto nel kernel con
+\texttt{CONFIG\_SECCOMP}, questo veniva attovato con \func{prctl} indicando
+l'opzione \const{PR\_SET\_SECCOMP}, che all'epoca supportava soltanto l'uso
+del valore \const{SECCOMP\_MODE\_STRICT} per \param{arg2}.
+
+Una volta abilitato il \textit{secure computing mode} 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}. Ogni altra \textit{system call} porterà all'emissione di un
+\signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}). In questa modalità di
+utilizzo i dati vengono letti o scritti grazie ad un socket o una
+\textit{pipe}, creati prima di lanciare il processo che eseguirà il codice non
+fidato, e per evitare problemi di sicurezza non saranno possibili altre
+operazioni se non quelle citate.
+
+
+% 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 esaminite 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{2.2cm}\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, 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 processo chiamante deve avere i 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 sono soddistatte 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*}
+\end{basedescript}
+
 
 
 % TODO: trattare keyctl (man 2 keyctl)
 
+
+
 % 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