``\textit{tracer process}''. Questa è una funzionalità fornita da
\textit{``Yama''}, uno specifico \textit{Linux Security Modules}, e serve a
consentire al processo indicato, quando le restrizioni introdotte da questo
- modulo sono attive, di usare \func{ptrace}\unavref{ (vedi
- sez.\ref{sec:process_ptrace})} sul processo chiamante, anche se quello
+ modulo sono attive, di usare \func{ptrace} (vedi
+ sez.~\ref{sec:process_ptrace}) sul processo chiamante, anche se quello
indicato non ne è un progenitore. Il valore \constd{PR\_SET\_PTRACER\_ANY}
consente a tutti i processi l'uso di \func{ptrace}. L'uso si \textit{Yama}
attiene alla gestione della sicurezza dei processi, e consente di introdurre
\end{basedescript}
-%\subsection{La funzione \func{ptrace}}
-%\label{sec:process_ptrace}
+\subsection{La funzione \func{ptrace}}
+\label{sec:process_ptrace}
%Da fare
% TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
% http://lwn.net/Articles/656675/
+\subsection{La funzione \func{kcmp}}
+\label{sec:process_kcmp}
+
+%Da fare
+% vedi man kcmp e man 2 open
+
\section{La gestione avanzata della creazione dei processi}
\label{sec:process_adv_creation}
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 attivato 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.
+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
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, utilizzando quella che viene usualmente chiamata una
- \itindex{symlink~race} \textit{symlink race}.\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}.}
+ 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
\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)
projects / gapil.git / blobdiff