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
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
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
\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.
Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai
kernel 2.5 è stata introdotta la struttura dei
-\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han
+\itindex{Linux~Security~Modules~(LSM)} \textit{Linux Security Modules} che han
permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)}
\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e
controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi
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 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
% 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.
+\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