1 \chapter{La gestione avanzata dei processi}
2 \label{cha:proc_advanced}
4 In questo capitolo affronteremo le tematiche relative alla gestione avanzata
5 dei processi, trattando le \textit{system call} dedicate alle funzionalità più
6 specifiche ed avanzate, il cui uso è in genere piuttosto ridotto. Inizieremo
7 con le funzioni che attengono agli aspetti di controllo, passando alle
8 gestione delle modalità di creazione ed alle funzionalità attinenti i
9 \textit{namespace} e le funzionalità avanzate relative alla gestione della
10 sicurezza. Infine affronteremo le funzioni di gestione per una serie di
11 funzionalità specialistiche come la gestione della virgola mobile, le porte di
14 \section{Funzioni di gestione e controllo}
15 \label{sec:proc_manage_control}
17 In questa sezione prenderemo in esame alcune specifiche \textit{system call}
18 dedicate al controllo processi sia per quanto riguarda l'impostazione di
19 caratteristiche specialistiche, che per quanto riguarda l'analisi ed il
20 controllo della loro esecuzione.
22 \subsection{La funzione \func{prctl}}
23 \label{sec:process_prctl}
25 Benché la gestione ordinaria dei processi possa essere effettuata attraverso
26 le funzioni che abbiamo già esaminato nei capitoli \ref{cha:process_interface}
27 e \ref{cha:process_handling}, esistono una serie di proprietà e
28 caratteristiche specifiche dei processi per la cui gestione è stata
29 predisposta una apposita \textit{system call} che fornisce una interfaccia
30 generica per tutte le operazioni specialistiche. La funzione di sistema è
31 \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è standardizzata
32 ed è specifica di Linux, anche se ne esiste una analoga in IRIX; è stata
33 introdotta con il kernel 2.1.57.}
37 \fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned
39 \phantom{int prctl(}unsigned long arg5)}
40 \fdesc{Esegue una operazione speciale sul processo corrente.}
43 {La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in
44 caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
45 valori diversi a seconda del tipo di operazione richiesta, sono possibili:
46 \errval{EACCESS}, \errval{EBADF}, \errval{EBUSY}, \errval{EFAULT},
47 \errval{EINVAL}, \errval{ENXIO}, \errval{EOPNOTSUPP} o \errval{EPERM}.}
50 La funzione ritorna in caso di successo un valore nullo o positivo, e $-1$ in
51 caso di errore. Il significato degli argomenti della funzione successivi al
52 primo, il valore di ritorno in caso di successo, il tipo di errore restituito
53 in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
54 argomento, \param{option}. Questo è un valore intero che identifica
55 l'operazione, e deve essere specificato con l'uso di una delle costanti
56 predefinite del seguente elenco.\footnote{l'elenco potrebbe non risultare
57 aggiornato, in quanto nuove operazioni vengono aggiunte nello sviluppo del
58 kernel.} Tratteremo esplicitamente per ciascuna di esse il significato del
59 il valore di ritorno in caso di successo, ma solo quando non corrisponde
60 all'ordinario valore nullo (dato per implicito).
62 %TODO: trattare PR_CAP_AMBIENT, dal 4.3
63 %TODO: trattare PR_CAP_FP_*, dal 4.0, solo per MIPS
64 %TODO: trattare PR_MPX_*_MANAGEMENT, dal 3.19
65 %TODO: trattare PR_*NO_NEW_PRIVS, dal 3.5
67 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
68 \item[\constd{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
69 \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
70 ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
71 delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
72 \textit{capabilities bounding set} del processo e zero altrimenti,
73 se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
74 Introdotta a partire dal kernel 2.6.25.
76 \item[\constd{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
77 \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
78 da tutti i suoi discendenti. La funzione cancella la capacità specificata
79 nell'argomento \param{arg2} con una delle costanti di
80 tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
81 processo. L'operazione richiede i privilegi di amministratore (la capacità
82 \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
83 \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
84 per le \textit{file capabilities} non è stato compilato nel kernel la
85 chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
88 \item[\constd{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
89 terminazione di un processo a causa di un segnale per il quale è prevista la
90 generazione di un file di \textit{core dump} (vedi
91 sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
92 viene attivato automaticamente, ma per evitare problemi di sicurezza (la
93 generazione di un file da parte di processi privilegiati può essere usata
94 per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
95 programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
96 sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
97 degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
99 L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
100 2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
101 valore 0 (espresso anche come \constd{SUID\_DUMP\_DISABLE}) di \param{arg2}
102 per disattivare il flag ed un valore 1 (espresso anche come
103 \constd{SUID\_DUMP\_USER}) per attivarlo. Nei kernel dal 2.6.13 al 2.6.17 è
104 stato supportato anche il valore 2, che causava la generazione di un
105 \textit{core dump} leggibile solo dall'amministratore, ma questa
106 funzionalità è stata rimossa per motivi di sicurezza, in quanto consentiva
107 ad un utente normale di creare un file di \textit{core dump} appartenente
108 all'amministratore in directory dove l'utente avrebbe avuto permessi di
109 accesso. Specificando un valore diverso da 0 o 1 si ottiene un errore di
112 \item[\constd{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
113 lo stato corrente del flag che controlla la effettiva generazione dei
114 \textit{core dump}. Introdotta a partire dal kernel 2.3.20.
116 \item[\constd{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
117 chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
118 sono: \constd{PR\_ENDIAN\_BIG} (\textit{big endian}),
119 \constd{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
120 \constd{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
121 PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
124 \item[\constd{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
125 processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
126 essere passata come di tipo ``\ctyp{int *}''. Introdotta a partire dal
127 kernel 2.6.18, solo su PowerPC.
129 \item[\constd{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
130 della virgola mobile su architettura ia64, secondo il valore
131 di \param{arg2}, si deve passare \constd{PR\_FPEMU\_NOPRINT} per emulare in
132 maniera trasparente l'accesso alle operazioni in virgola mobile, o
133 \constd{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
134 \signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
135 dal kernel 2.4.18, solo su architettura ia64.
137 \item[\constd{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
138 dell'emulazione della virgola mobile, salvato all'indirizzo puntato
139 da \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
140 partire dal kernel 2.4.18, solo su architettura ia64.
142 \item[\constd{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
143 mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
144 I valori possibili sono:
146 \item \constd{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
147 \item \constd{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
148 \item \constd{PR\_FP\_EXC\_OVF} per gli overflow,
149 \item \constd{PR\_FP\_EXC\_UND} per gli underflow,
150 \item \constd{PR\_FP\_EXC\_RES} per risultati non esatti,
151 \item \constd{PR\_FP\_EXC\_INV} per operazioni invalide,
152 \item \constd{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
153 \item \constd{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
154 asincrona non recuperabile,
155 \item \constd{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
156 asincrona recuperabile,
157 \item \constd{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
158 eccezione.\footnote{trattasi di gestione specialistica della gestione
159 delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
160 momento vanno al di là dello scopo di questo testo.}
162 Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
164 \item[\constd{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
165 delle operazioni in virgola mobile, salvata all'indirizzo
166 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta
167 a partire dal kernel 2.4.21, solo su PowerPC.
169 \item[\constd{PR\_SET\_KEEPCAPS}] Consente di controllare quali
170 \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
171 \ids{UID} del processo (per i dettagli si veda
172 sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
173 pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
174 per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
175 mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
176 L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
177 flag \const{SECURE\_KEEP\_CAPS} dei \textit{securebits} (vedi
178 sez.~\ref{sec:proc_capabilities} e l'uso di \const{PR\_SET\_SECUREBITS} più
179 avanti) e si è impostato con essi \const{SECURE\_KEEP\_CAPS\_LOCKED} si
180 otterrà un errore di \errval{EPERM}. Introdotta a partire dal kernel
183 \item[\constd{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
184 il valore del flag di controllo delle \textit{capabilities} impostato con
185 \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
187 \item[\constd{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
188 stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
189 nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
190 terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
192 \item[\constd{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
193 stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}'';
194 si devono allocare per questo almeno 16 byte, e il nome sarà terminato da
195 NUL se più corto. Introdotta a partire dal kernel 2.6.9.
197 \item[\constd{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
198 segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
199 terminazione del proprio processo padre; in sostanza consente di invertire
200 il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
201 numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
202 automaticamente cancellato per un processo figlio creato con \func{fork}.
203 Introdotta a partire dal kernel 2.1.57.
205 \item[\constd{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
206 emesso alla terminazione del padre, salvato all'indirizzo
207 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
208 partire dal kernel 2.3.15.
210 \item[\constd{PR\_SET\_PTRACER}] Imposta un \ids{PID} per il ``\textit{tracer
211 process}'' usando \param{arg2}. Una impostazione successiva sovrascrive la
212 precedente, ed un valore nullo cancella la disponibilità di un
213 ``\textit{tracer process}''. Questa è una funzionalità fornita da
214 \textit{``Yama''}, uno specifico \textit{Linux Security Modules}, e serve a
215 consentire al processo indicato, quando le restrizioni introdotte da questo
216 modulo sono attive, di usare \func{ptrace} (vedi
217 sez.~\ref{sec:process_ptrace}) sul processo chiamante, anche se quello
218 indicato non ne è un progenitore. Il valore \constd{PR\_SET\_PTRACER\_ANY}
219 consente a tutti i processi l'uso di \func{ptrace}. L'uso si \textit{Yama}
220 attiene alla gestione della sicurezza dei processi, e consente di introdurre
221 una restrizione all'uso di \func{ptrace}, che è spesso sorgente di
222 compromissioni. Si tratta di un uso specialistico che va al di là dello
223 scopo di queste dispense, per i dettagli si consulti la documentazione su
224 \textit{Yama} nei sorgenti del kernel. Introdotta a partire dal kernel 3.4.
226 \item[\constd{PR\_SET\_SECCOMP}] Attiva il \textit{secure computing mode} per
227 il processo corrente. Introdotta a partire dal kernel 2.6.23 la funzionalità
228 è stata ulteriormente estesa con il kernel 3.5, salvo poi diventare un
229 sottoinsieme della \textit{system call} \func{seccomp} a partire dal kernel
230 3.17. Prevede che si indichi per \param{arg2} il valore
231 \const{SECCOMP\_MODE\_STRICT} (unico possibile fino al kernel 2.6.23) per
232 selezionare il cosiddetto \textit{strict mode} o, dal kernel 3.5,
233 \const{SECCOMP\_MODE\_FILTER} per usare il \textit{filter mode}. Tratteremo
234 questa opzione nei dettagli più avanti, in sez.~\ref{sec:procadv_seccomp},
235 quando affronteremo l'argomento del \textit{Secure Computing}.
237 \item[\constd{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
238 lo stato corrente del \textit{secure computing mode}. Fino al kernel 3.5,
239 quando era possibile solo lo \textit{strict mode}, la funzione era
240 totalmente inutile in quanto l'unico valore ottenibile era 0 in assenza di
241 \textit{secure computing}, dato che la chiamata di questa funzione in
242 \textit{strict mode} avrebbe comportato l'emissione di \signal{SIGKILL} per
243 il chiamante. La funzione però, a partire dal kernel 2.6.23, era stata
244 comunque definita per eventuali estensioni future, ed infatti con
245 l'introduzione del \textit{filter mode} con il kernel 3.5, se essa viene
246 inclusa nelle funzioni consentite restituisce il valore 2 quando il
247 \textit{secure computing mode} è attivo (se non inclusa si avrà di nuovo un
250 \item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
251 processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
252 significato dei \textit{securebits} si veda
253 sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
254 tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
255 richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
256 altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
257 partire dal kernel 2.6.26.
259 \item[\constd{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
260 funzione l'impostazione corrente per i \textit{securebits}. Introdotta a
261 partire dal kernel 2.6.26.
263 \item[\constd{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
264 processo da indicare con il valore di \param{arg2}, attualmente i valori
265 possibili sono due, con \constd{PR\_TIMING\_STATISTICAL} si usa il metodo
266 statistico tradizionale, con \constd{PR\_TIMING\_TIMESTAMP} il più accurato
267 basato su dei \textit{timestamp}, quest'ultimo però non è ancora
268 implementato ed il suo uso comporta la restituzione di un errore di
269 \errval{EINVAL}. Introdotta a partire dal kernel 2.6.0-test4.
271 \item[\constd{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
272 il metodo di temporizzazione del processo attualmente in uso (uno dei due
273 valori citati per \const{PR\_SET\_TIMING}). Introdotta a partire dal kernel
276 \item[\constd{PR\_SET\_TSC}] Imposta il flag che indica se il processo
277 chiamante può leggere il registro di processore contenente il contatore dei
278 \textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
279 valore di \param{arg2}. Si deve specificare \constd{PR\_TSC\_ENABLE} per
280 abilitare la lettura o \constd{PR\_TSC\_SIGSEGV} per disabilitarla con la
281 generazione di un segnale di \signal{SIGSEGV} (vedi
282 sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
283 disabilitata se si attiva il \textit{secure computing mode} (vedi
284 \const{PR\_SET\_SECCOMP} e sez.~\ref{sec:procadv_seccomp}). Introdotta a
285 partire dal kernel 2.6.26, solo su x86.
287 \item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
288 lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
289 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
290 partire dal kernel 2.6.26, solo su x86.
291 % articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
292 % http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
293 % http://en.wikipedia.org/wiki/Time_Stamp_Counter
295 \item[\constd{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
296 a indirizzi di memoria non allineati, che in varie architetture risultano
297 illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
298 valore \constd{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
299 ed il valore \constd{PR\_UNALIGN\_SIGBUS} per generare un segnale di
300 \signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
301 allineato. Introdotta con diverse versioni su diverse architetture.
303 \item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
304 per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
305 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
306 diverse versioni su diverse architetture.
307 \item[\const{PR\_MCE\_KILL}] Imposta la politica di gestione degli errori
308 dovuti a corruzione della memoria per problemi hardware. Questo tipo di
309 errori vengono riportati dall'hardware di controllo della RAM e vengono
310 gestiti dal kernel,\footnote{la funzionalità è disponibile solo sulle
311 piattaforme più avanzate che hanno il supporto hardware per questo tipo di
312 controlli.} ma devono essere opportunamente riportati ai processi che
313 usano quella parte di RAM che presenta errori; nel caso specifico questo
314 avviene attraverso l'emissione di un segnale di \signal{SIGBUS} (vedi
315 sez.~\ref{sec:sig_prog_error}).\footnote{in particolare viene anche
316 impostato il valore di \var{si\_code} in \struct{siginfo\_t} a
317 \const{BUS\_MCEERR\_AO}; per il significato di tutto questo si faccia
318 riferimento alla trattazione di sez.~\ref{sec:sig_sigaction}.}
320 Il comportamento di default prevede che per tutti i processi si applichi la
321 politica generale di sistema definita nel file
322 \sysctlfiled{vm/memory\_failure\_early\_kill}, ma specificando
323 per \param{arg2} il valore \constd{PR\_MCE\_KILL\_SET} è possibile impostare
324 con il contenuto di \param{arg3} una politica specifica del processo
325 chiamante. Si può tornare alla politica di default del sistema utilizzando
326 invece per \param{arg2} il valore \constd{PR\_MCE\_KILL\_CLEAR}. In tutti i
327 casi, per compatibilità con eventuali estensioni future, tutti i valori
328 degli argomenti non utilizzati devono essere esplicitamente posti a zero,
329 pena il fallimento della chiamata con un errore di \errval{EINVAL}.
331 In caso di impostazione di una politica specifica del processo con
332 \const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
333 due, che corrispondono anche al valore che si trova nell'impostazione
334 generale di sistema di \texttt{memory\_failure\_early\_kill}, con
335 \constd{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
336 \signal{SIGBUS} non appena viene rilevato un errore, mentre con
337 \constd{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
338 tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
339 rispettivamente ai valori 1 e 0 di
340 \texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
341 viene immediatamente inviato il segnale a tutti i processi che hanno la
342 memoria corrotta mappata all'interno del loro spazio degli indirizzi, nel
343 secondo caso prima la pagina di memoria viene tolta dallo spazio degli
344 indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
345 processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
346 terzo valore, \constd{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
347 per il processo la politica di default.\footnote{si presume la politica di
348 default corrente, in modo da non essere influenzati da un eventuale
349 successivo cambiamento della stessa.} Introdotta a partire dal kernel
351 \item[\constd{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
352 funzione la politica di gestione degli errori dovuti a corruzione della
353 memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
354 nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
355 partire dal kernel 2.6.32.
356 \itindbeg{child~reaper}
357 \item[\constd{PR\_SET\_CHILD\_SUBREAPER}] Se \param{arg2} è diverso da zero
358 imposta l'attributo di \textit{child reaper} per il processo, se nullo lo
359 cancella. Lo stato di \textit{child reaper} è una funzionalità, introdotta
360 con il kernel 3.4, che consente di far svolgere al processo che ha questo
361 attributo il ruolo di ``\textsl{genitore adottivo}'' per tutti i processi
362 suoi ``\textsl{discendenti}'' che diventano orfani, in questo modo il
363 processo potrà ricevere gli stati di terminazione alla loro uscita,
364 sostituendo in questo ruolo \cmd{init} (si ricordi quanto illustrato in
365 sez.~\ref{sec:proc_termination}). Il meccanismo è stato introdotto ad uso
366 dei programmi di gestione dei servizi, per consentire loro di ricevere gli
367 stati di terminazione di tutti i processi che lanciano, anche se questi
368 eseguono una doppia \func{fork}; nel comportamento ordinario infatti questi
369 verrebbero adottati da \cmd{init} ed il programma che li ha lanciati non
370 sarebbe più in grado di riceverne lo stato di terminazione. Se un processo
371 con lo stato di \textit{child reaper} termina prima dei suoi discendenti,
372 svolgerà questo ruolo il più prossimo antenato ad avere lo stato di
373 \textit{child reaper},
374 \item[\constd{PR\_GET\_CHILD\_SUBREAPER}] Ottiene l'impostazione relativa allo
375 lo stato di \textit{child reaper} del processo chiamante, salvata come
376 \textit{value result} all'indirizzo puntato da \param{arg2} (da indicare
377 come di tipo \code{int *}). Il valore viene letto come valore logico, se
378 diverso da 0 lo stato di \textit{child reaper} è attivo altrimenti è
379 disattivo. Introdotta a partire dal kernel 3.4.
380 \itindend{child~reaper}
383 % TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi
384 % http://lwn.net/Articles/582712/
386 % TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i
387 % parametri di base del layout dello spazio di indirizzi di un processo (area
388 % codice e dati, stack, brack pointer ecc. vedi
389 % http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e
391 % TODO documentare ARCH_SET_CPUID e ARCH_GET_CPUID, introdotte con il kernel
392 % 4.12, vedi https://lwn.net/Articles/721182/
393 \label{sec:prctl_operation}
397 \subsection{La funzione \func{ptrace}}
398 \label{sec:process_ptrace}
402 % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
403 % TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
404 % http://lwn.net/Articles/529060/)
405 % TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
407 % TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
408 % http://lwn.net/Articles/656675/
410 \subsection{La funzione \func{kcmp}}
411 \label{sec:process_kcmp}
414 % vedi man kcmp e man 2 open
417 \section{La gestione avanzata della creazione dei processi}
418 \label{sec:process_adv_creation}
420 In questa sezione tratteremo le funzionalità avanzate relative alla creazione
421 dei processi e del loro ambiente, sia per quanto riguarda l'utilizzo delle
422 stesse per la creazione dei \textit{thread} che per la gestione dei
423 \textit{namespace} che sono alla base dei cosiddetti \textit{container}.
426 \subsection{La \textit{system call} \func{clone}}
427 \label{sec:process_clone}
429 La funzione tradizionale con cui creare un nuovo processo in un sistema
430 Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
431 l'introduzione del supporto del kernel per i \textit{thread}\unavref{ (vedi
432 cap.~\ref{cha:threads})}, si è avuta la necessità di una interfaccia che
433 consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
434 processi, che poi è stata utilizzata anche per fornire supporto per le
435 tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container})
436 su cui torneremo in sez.~\ref{sec:process_namespaces}.
438 Per questo l'interfaccia per la creazione di un nuovo processo è stata
439 delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
440 di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
441 più che di nuovi processi si può parlare della creazioni di nuovi
442 ``\textit{task}'' del kernel che possono assumere la veste sia di un processo
443 classico isolato dagli altri come quelli trattati finora, che di un
444 \textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
445 il nuovo processo creato, come quelli che vedremo in
446 sez.~\ref{sec:linux_thread}. Per evitare confusione fra \textit{thread} e
447 processi ordinari, abbiamo deciso di usare la nomenclatura \textit{task} per
448 indicare la unità di esecuzione generica messa a disposizione del kernel che
449 \texttt{sys\_clone} permette di creare.
451 La \textit{system call} richiede soltanto due argomenti: il
452 primo, \param{flags}, consente di controllare le modalità di creazione del
453 nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
454 dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
455 si intende creare un \textit{thread}. L'esecuzione del programma creato da
456 \func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
459 La necessità di avere uno \textit{stack} alternativo c'è solo quando si
460 intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
461 vede esattamente la stessa memoria del \textit{task}
462 ``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
463 il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
464 da essa creato, senza nessuna delle implicazioni che il concetto ha per i
465 processi.} e nella sua esecuzione alla prima chiamata di una funzione
466 andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
467 quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
470 Per evitare di doversi garantire contro la evidente possibilità di
471 \textit{race condition} che questa situazione comporta (vedi
472 sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
473 necessario che il chiamante allochi preventivamente un'area di memoria. In
474 genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
475 imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
476 non utilizzarlo direttamente nel processo chiamante.
478 In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
479 non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
480 presente inoltre che in molte architetture di processore lo \textit{stack}
481 cresce verso il basso, pertanto in tal caso non si dovrà specificare
482 per \param{child\_stack} il puntatore restituito da \func{malloc}, ma un
483 puntatore alla fine del buffer da essa allocato.
485 Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
486 memoria, la \textit{system call}, a differenza della funzione di libreria che
487 vedremo a breve, consente anche di passare per \param{child\_stack} il valore
488 \val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
489 processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
490 cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
491 in questo caso si applica la semantica del \textit{copy on write} illustrata
492 in sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
493 automaticamente copiate come le altre e il nuovo processo avrà un suo
494 \textit{stack} totalmente indipendente da quello del padre.
496 Dato che l'uso principale della nuova \textit{system call} è quello relativo
497 alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
498 libreria con una sintassi diversa, orientata a questo scopo, e la
499 \textit{system call} resta accessibile solo se invocata esplicitamente come
500 visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
501 \textit{system call} non è disponibile la chiamata veloce con
502 \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
503 \funcd{clone} ed il suo prototipo è:
507 \fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
509 \phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
510 \fdesc{Crea un nuovo processo o \textit{thread}.}
512 {La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
513 di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
516 \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
517 \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
518 un valore nullo per \param{child\_stack}.
519 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
520 \texttt{task\_struct} o per copiare le parti del contesto del chiamante
521 necessarie al nuovo \textit{task}.
522 \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
523 richiesti dai flag indicati.
527 % NOTE: una pagina con la descrizione degli argomenti:
528 % * http://www.lindevdoc.org/wiki/Clone
530 La funzione prende come primo argomento \param{fn} il puntatore alla funzione
531 che verrà messa in esecuzione nel nuovo processo, che può avere un unico
532 argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
533 terzo argomento \param{arg}. Per quanto il precedente prototipo possa
534 intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
535 definire una qualunque funzione \param{fn} che restituisce un intero ed ha
536 come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
539 Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
540 non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
541 di ritorno della funzione (o quello specificato con \func{exit}) verrà
542 utilizzato come stato di uscita della funzione. I tre
543 argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
544 presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
545 le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
546 Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
547 utilizzati soltanto se si sono specificati rispettivamente i flag
548 \const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
549 \const{CLONE\_CHILD\_SETTID}.
551 La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
552 \texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
553 al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
554 un processo ordinario e non un \textit{thread}.
556 Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
557 nuovo processo da essa creato, è controllato principalmente
558 dall'argomento \param{flags}, che deve essere specificato come maschera
559 binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
560 elenco, che illustra quelle attualmente disponibili:\footnote{si fa
561 riferimento al momento della stesura di questa sezione, cioè con il kernel
564 \begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
566 \item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
567 ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un
568 riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a
569 quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei
570 \textit{thread} ed è presente dal kernel 2.5.49.
572 \item[\constd{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
573 figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
574 utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
577 \item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
578 padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
579 questo significa che ogni \textit{file descriptor} aperto da un processo
580 verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
581 \textit{file descriptor flag} di un \textit{file descriptor} verrà per
584 Se non viene impostato il processo figlio eredita una copia della
585 \textit{file descriptor table} del padre e vale la semantica classica della
586 gestione dei \textit{file descriptor}, che costituisce il comportamento
587 ordinario di un sistema unix-like e che illustreremo in dettaglio in
588 sez.~\ref{sec:file_shared_access}.
590 \item[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
591 condividerà con il padre le informazioni relative all'albero dei file, ed in
592 particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
593 stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
594 \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
595 qualunque di queste caratteristiche in un processo, avrà effetto anche
596 sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
597 informazioni, che saranno così indipendenti per i due processi, come avviene
598 nel comportamento ordinario di un sistema unix-like.
600 \item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo processo
601 condividerà con il padre il contesto dell'I/O, altrimenti, come avviene nel
602 comportamento ordinario con una \func{fork} otterrà un suo contesto
605 Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
606 sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
607 questi vengono trattati come se fossero lo stesso, condividendo il tempo per
608 l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
609 questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
610 dello stesso processo (ad esempio con le funzioni di I/O asincrono di
611 sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
613 %TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
614 %relativa sezione da creare a parte
616 % \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
617 % introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
618 % processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
619 % di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
620 % di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
621 % tutti quegli oggetti che non vegono identificati con un \textit{pathname}
622 % sull'albero dei file.
624 % L'uso di questo flag richiede privilegi di amministratore (più precisamente
625 % la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
626 % con \const{CLONE\_SYSVSEM}.
628 % \item[\constd{CLONE\_NEWNET}]
629 % \item[\constd{CLONE\_NEWNS}]
630 % \item[\constd{CLONE\_NEWPID}]
631 % \item[\constd{CLONE\_NEWUTS}]
634 % TODO trattare CLONE_NEWCGROUP introdotto con il kernel 4.6, vedi
635 % http://lwn.net/Articles/680566/
637 \item[\constd{CLONE\_PARENT}]
638 \item[\constd{CLONE\_PARENT\_SETTID}]
639 \item[\constd{CLONE\_PID}]
641 \item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
642 chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
643 figlio viene tracciato.
645 \item[\constd{CLONE\_SETTLS}]
646 \item[\constd{CLONE\_SIGHAND}]
647 \item[\constd{CLONE\_STOPPED}]
648 \item[\constd{CLONE\_SYSVSEM}]
649 \item[\constd{CLONE\_THREAD}]
651 \item[\constd{CLONE\_UNTRACED}] se questo flag viene impostato un processo non
652 può più forzare \const{CLONE\_PTRACE} su questo processo.
654 \item[\constd{CLONE\_VFORK}] se questo flag viene impostato il chiamante viene
655 fermato fintato che il figlio appena creato non rilascia la sua memoria
656 virtuale con una chiamata a \func{exec} o \func{exit}, viene quindi
657 replicato il comportamento di \func{vfork}.
659 \item[\constd{CLONE\_VM}] se questo flag viene impostato il nuovo processo
660 condividerà con il padre la stessa memoria virtuale, e le scritture in
661 memoria fatte da uno qualunque dei processi saranno visibili dall'altro,
662 così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}).
664 Se non viene impostato il processo figlio otterrà una copia dello spazio
665 degli indirizzi e si otterrà il comportamento ordinario di un processo di un
666 sistema unix-like creato con la funzione \func{fork}.
671 \subsection{La gestione dei \textit{namespace}}
672 \label{sec:process_namespaces}
675 Come accennato all'inizio di sez.~\ref{sec:process_clone} oltre al controllo
676 delle caratteristiche dei processi usate per la creazione dei \textit{thread},
677 l'uso di \func{clone} consente, ad uso delle nuove funzionalità di
678 virtualizzazione dei processi, di creare nuovi ``\textit{namespace}'' per una
679 serie di proprietà generali (come l'elenco dei \ids{PID}, l'albero dei file, i
680 \textit{mount point}, la rete, il sistema di IPC, ecc.).
682 L'uso dei ``\textit{namespace}'' consente creare gruppi di processi che vedono
683 le suddette proprietà in maniera indipendente fra loro. I processi di ciascun
684 gruppo vengono così eseguiti come in una sorta di spazio separato da quello
685 degli altri gruppi, che costituisce poi quello che viene chiamato un
696 %TODO sezione separata sui namespace
698 %TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
700 %TODO: trattare la funzione setns e i namespace file descriptors (vedi
701 % http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
702 % informazioni su setns qui: http://lwn.net/Articles/532748/
703 % http://lwn.net/Articles/531498/
706 \section{La gestione avanzata della sicurezza}
707 \label{sec:process_security}
709 Tratteremo in questa sezione le funzionalità più avanzate relative alla
710 gestione della sicurezza ed il controllo degli accessi all'interno dei
711 processi, a partire dalle \textit{capabilities} e dalle funzionalità di
712 \textit{Secure Computing}. Esamineremo inoltre tutte le altre funzionalità
713 relative alla sicurezza come gestione delle chiavi crittografiche e varie
714 estensioni e funzionalità disponibili su questo argomento.
718 \subsection{La gestione delle \textit{capabilities}}
719 \label{sec:proc_capabilities}
721 \itindbeg{capabilities}
723 Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
724 gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
725 fornire all'amministratore dei poteri troppo ampi. Questo comporta che anche
726 quando si siano predisposte delle misure di protezione per in essere in grado
727 di difendersi dagli effetti di una eventuale compromissione del sistema (come
728 montare un filesystem in sola lettura per impedirne modifiche, o marcare un
729 file come immutabile) una volta che questa sia stata effettuata e si siano
730 ottenuti i privilegi di amministratore, queste misure potranno essere comunque
731 rimosse (nei casi elencati nella precedente nota si potrà sempre rimontare il
732 sistema in lettura-scrittura, o togliere l'attributo di immutabilità).
734 Il problema consiste nel fatto che nell'architettura tradizionale di un
735 sistema unix-like i controlli di accesso sono basati su un solo livello di
736 separazione: per i processi normali essi sono posti in atto, mentre per i
737 processi con i privilegi di amministratore essi non vengono neppure eseguiti.
738 Per questo motivo non era previsto alcun modo per evitare che un processo con
739 diritti di amministratore non potesse eseguire certe operazioni, o per cedere
740 definitivamente alcuni privilegi da un certo momento in poi.
742 Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai
743 kernel 2.5 è stata introdotta la struttura dei
744 \itindex{Linux~Security~Modules~(LSM)} \textit{Linux Security Modules} che han
745 permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)}
746 \textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e
747 controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi
748 possono essere usati dai programmi e trasferiti agli utenti, con la creazione
749 di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo},
750 \textit{AppArmor}) che consentono di superare l'architettura tradizionale dei
751 permessi basati sul modello classico del controllo di accesso chiamato
752 \itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access
755 Ma già in precedenza, a partire dai kernel della serie 2.2, era stato
756 introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
757 suddividere i vari privilegi tradizionalmente associati all'amministratore in
758 un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
759 potessero essere abilitate e disabilitate in maniera indipendente per ciascun
760 processo con privilegi di amministratore, permettendo così una granularità
761 molto più fine nella distribuzione degli stessi che evitasse la situazione
762 originaria di ``\textsl{tutto o nulla}''.
764 \itindbeg{file~capabilities}
766 Il meccanismo completo delle \textit{capabilities} (l'implementazione si rifà
767 ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi
768 abbandonato) prevede inoltre la possibilità di associare le stesse ai singoli
769 file eseguibili, in modo da poter stabilire quali capacità possono essere
770 utilizzate quando viene messo in esecuzione uno specifico programma; ma il
771 supporto per questa funzionalità, chiamata \textit{file capabilities}, è stato
772 introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva essere
773 il programma stesso ad eseguire una riduzione esplicita delle sue capacità,
774 cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la presenza
775 di meccanismi alternativi per ottenere limitazioni delle capacità
776 dell'amministratore a livello di sistema operativo, come \textit{SELinux}.
778 Con questo supporto e con le ulteriori modifiche introdotte con il kernel
779 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
780 rivoluzionato, rendendolo più aderente alle intenzioni originali dello
781 standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
782 capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
783 cosiddetto \textit{capabilities bounding set}. Ulteriori modifiche sono state
784 apportate con il kernel 2.6.26 per consentire la rimozione non ripristinabile
785 dei privilegi di amministratore. Questo fa sì che il significato ed il
786 comportamento del kernel finisca per dipendere dalla versione dello stesso e
787 dal fatto che le nuove \textit{file capabilities} siano abilitate o meno. Per
788 capire meglio la situazione e cosa è cambiato conviene allora spiegare con
789 maggiori dettagli come funziona il meccanismo delle \textit{capabilities}.
791 Il primo passo per frazionare i privilegi garantiti all'amministratore,
792 supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
793 cui a ciascun processo sono stati associati tre distinti insiemi di
794 \textit{capabilities}, denominati rispettivamente \textit{permitted},
795 \textit{inheritable} ed \textit{effective}. Questi insiemi vengono mantenuti
796 in forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come
797 i vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
798 \texttt{task\_struct} di ciascun processo (vedi
799 fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
800 \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
801 \texttt{kernel\_cap\_t}; questo era, fino al kernel 2.6.25 definito come
802 intero a 32 bit per un massimo di 32 \textit{capabilities} distinte,
803 attualmente è stato aggiornato ad un vettore in grado di mantenerne fino a
804 64.} in cui ciascun bit corrisponde ad una capacità diversa.
806 L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
807 per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
808 sono mantenuti i diversi insiemi di identificatori di
809 sez.~\ref{sec:proc_setuid}; il loro significato, che è rimasto sostanzialmente
810 lo stesso anche dopo le modifiche seguite alla introduzione delle
811 \textit{file capabilities} è il seguente:
812 \begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
813 \item[\textit{permitted}] l'insieme delle \textit{capabilities}
814 ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
815 \textsl{può} impostare come \textsl{effettive} o come
816 \textsl{ereditabili}. Se un processo cancella una capacità da questo insieme
817 non potrà più riassumerla.\footnote{questo nei casi ordinari, sono
818 previste però una serie di eccezioni, dipendenti anche dal tipo di
819 supporto, che vedremo meglio in seguito dato il notevole intreccio nella
821 \item[\textit{inheritable}] l'insieme delle \textit{capabilities}
822 ``\textsl{ereditabili}'', cioè di quelle che verranno trasmesse come insieme
823 delle \textsl{permesse} ad un nuovo programma eseguito attraverso una
824 chiamata ad \func{exec}.
825 \item[\textit{effective}] l'insieme delle \textit{capabilities}
826 ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
827 kernel quando deve eseguire il controllo di accesso per le varie operazioni
828 compiute dal processo.
829 \label{sec:capabilities_set}
832 Con l'introduzione delle \textit{file capabilities} sono stati introdotti
833 altri tre insiemi associabili a ciascun file.\footnote{la realizzazione viene
834 eseguita con l'uso di uno specifico attributo esteso,
835 \texttt{security.capability}, la cui modifica è riservata, (come illustrato
836 in sez.~\ref{sec:file_xattr}) ai processi dotato della capacità
837 \const{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
838 soltanto quando il file che le porta viene eseguito come programma con una
839 \func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
840 con maggiori privilegi; in sostanza sono una sorta di estensione del
841 \acr{suid} bit limitato ai privilegi di amministratore. Anche questi tre
842 insiemi sono identificati con gli stessi nomi di quello dei processi, ma il
843 loro significato è diverso:
844 \begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
845 \item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
846 delle capacità che con l'esecuzione del programma verranno aggiunte alle
847 capacità \textsl{permesse} del processo.
848 \item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
849 l'insieme delle capacità che con l'esecuzione del programma possono essere
850 ereditate dal processo originario (che cioè non vengono tolte
851 dall'\textit{inheritable set} del processo originale all'esecuzione di
853 \item[\textit{effective}] in questo caso non si tratta di un insieme ma di un
854 unico valore logico; se attivo all'esecuzione del programma tutte le
855 capacità che risulterebbero \textsl{permesse} verranno pure attivate,
856 inserendole automaticamente nelle \textsl{effettive}, se disattivato nessuna
857 capacità verrà attivata (cioè l'\textit{effective set} resterà vuoto).
860 \itindbeg{capabilities~bounding~set}
862 Infine come accennato, esiste un ulteriore insieme, chiamato
863 \textit{capabilities bounding set}, il cui scopo è quello di costituire un
864 limite alle capacità che possono essere attivate per un programma. Il suo
865 funzionamento però è stato notevolmente modificato con l'introduzione delle
866 \textit{file capabilities} e si deve pertanto prendere in considerazione una
867 casistica assai complessa.
869 Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
870 \textit{file capabilities}, il \textit{capabilities bounding set} è un
871 parametro generale di sistema, il cui valore viene riportato nel file
872 \sysctlfiled{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
873 compilazione del kernel, e da sempre ha previsto come default la presenza di
874 tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In questa
875 situazione solo il primo processo eseguito nel sistema (quello con
876 \textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di
877 modificarlo; ogni processo eseguito successivamente, se dotato dei privilegi
878 di amministratore, è in grado soltanto di rimuovere una delle
879 \textit{capabilities} già presenti dell'insieme.\footnote{per essere precisi
880 occorre la capacità \const{CAP\_SYS\_MODULE}.}
882 In questo caso l'effetto complessivo del \textit{capabilities bounding set} è
883 che solo le capacità in esso presenti possono essere trasmesse ad un altro
884 programma attraverso una \func{exec}. Questo in sostanza significa che se un
885 qualunque programma elimina da esso una capacità, considerato che
886 \texttt{init} (almeno nelle versioni ordinarie) non supporta la reimpostazione
887 del \textit{bounding set}, questa non sarà più disponibile per nessun processo
888 a meno di un riavvio, eliminando così in forma definitiva quella capacità per
889 tutti, compreso l'amministratore.\footnote{la qual cosa, visto il default
890 usato per il \textit{capabilities bounding set}, significa anche che
891 \const{CAP\_SETPCAP} non è stata praticamente mai usata nella sua forma
894 Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
895 è diventato una proprietà di ciascun processo, che viene propagata invariata
896 sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
897 \sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
898 ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
899 presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
901 Con questo nuovo meccanismo il \textit{bounding set} continua a ricoprire un
902 ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
903 limite alle capacità che possono essere aggiunte al processo in quanto
904 presenti nel \textit{permitted set} del programma messo in esecuzione, in
905 sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
906 suo \textit{permitted set} (quello del file) solo se questa è anche nel
907 \textit{bounding set} (del processo). In questo modo si possono rimuovere
908 definitivamente certe capacità da un processo, anche qualora questo dovesse
909 eseguire un programma privilegiato che prevede di riassegnarle.
911 Si tenga presente però che in questo caso il \textit{bounding set} blocca
912 esclusivamente le capacità indicate nel \textit{permitted set} del programma
913 che verrebbero attivate in caso di esecuzione, e non quelle eventualmente già
914 presenti nell'\textit{inheritable set} del processo (ad esempio perché
915 presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
916 eseguendo un programma che abbia anche lui dette capacità nel suo
917 \textit{inheritable set} queste verrebbero assegnate.
919 In questa seconda versione inoltre il \textit{bounding set} costituisce anche
920 un limite per le capacità che possono essere aggiunte all'\textit{inheritable
921 set} del processo stesso con \func{capset}, sempre nel senso che queste
922 devono essere presenti nel \textit{bounding set} oltre che nel
923 \textit{permitted set} del processo. Questo limite vale anche per processi con
924 i privilegi di amministratore,\footnote{si tratta sempre di avere la
925 \textit{capability} \const{CAP\_SETPCAP}.} per i quali invece non vale la
926 condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
927 set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
928 scopo anche in questo caso è ottenere una rimozione definitiva della
929 possibilità di passare una capacità rimossa dal \textit{bounding set}.}
931 Come si può notare per fare ricorso alle \textit{capabilities} occorre
932 comunque farsi carico di una notevole complessità di gestione, aggravata dalla
933 presenza di una radicale modifica del loro funzionamento con l'introduzione
934 delle \textit{file capabilities}. Considerato che il meccanismo originale era
935 incompleto e decisamente problematico nel caso di programmi che non ne
936 sapessero tener conto,\footnote{c'è stato un grosso problema di sicurezza con
937 \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
938 dall'\textit{inheritable set} di un processo si ottenne di far fallire
939 \func{setuid} in maniera inaspettata per il programma (che aspettandosi
940 sempre il successo della funzione non ne controllava lo stato di uscita) con
941 la conseguenza di effettuare come amministratore operazioni che altrimenti
942 sarebbero state eseguite, senza poter apportare danni, da utente normale.}
943 ci soffermeremo solo sulla implementazione completa presente a partire dal
944 kernel 2.6.25, tralasciando ulteriori dettagli riguardo la versione
947 Riassumendo le regole finora illustrate tutte le \textit{capabilities} vengono
948 ereditate senza modifiche attraverso una \func{fork} mentre, indicati con
949 \texttt{orig\_*} i valori degli insiemi del processo chiamante, con
950 \texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
951 \textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
952 processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
953 formula espressa dal seguente pseudo-codice C:
955 \includecodesnip{listati/cap-results.c}
957 % \begin{figure}[!htbp]
958 % \footnotesize \centering
959 % \begin{minipage}[c]{12cm}
960 % \includecodesnip{listati/cap-results.c}
962 % \caption{Espressione della modifica delle \textit{capabilities} attraverso
964 % \label{fig:cap_across_exec}
967 \noindent e si noti come in particolare il \textit{capabilities bounding set}
968 non venga comunque modificato e resti lo stesso sia attraverso una \func{fork}
969 che attraverso una \func{exec}.
972 \itindend{capabilities~bounding~set}
974 A queste regole se ne aggiungono delle altre che servono a riprodurre il
975 comportamento tradizionale di un sistema unix-like in tutta una serie di
976 circostanze. La prima di queste è relativa a quello che avviene quando si
977 esegue un file senza \textit{capabilities}; se infatti si considerasse questo
978 equivalente al non averne assegnata alcuna, non essendo presenti capacità né
979 nel \textit{permitted set} né nell'\textit{inheritable set} del file,
980 nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
981 privilegi originali dal processo.
983 Per questo motivo se un programma senza \textit{capabilities} assegnate viene
984 eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come
985 se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
986 tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
987 col risultato di fornire comunque al processo tutte le capacità presenti nel
988 proprio \textit{bounding set}. Lo stesso avviene quando l'eseguibile ha attivo
989 il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
990 riesce così a riottenere il comportamento classico di un sistema unix-like.
992 Una seconda circostanza è quella relativa a cosa succede alle
993 \textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
994 nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
995 cedere o riottenere i privilegi di amministratore) che si possono effettuare
996 con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
997 casistica è di nuovo alquanto complessa, considerata anche la presenza dei
998 diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
1001 \item se si passa da \ids{UID} effettivo nullo a non nullo
1002 l'\textit{effective set} del processo viene totalmente azzerato, se
1003 viceversa si passa da \ids{UID} effettivo non nullo a nullo il
1004 \textit{permitted set} viene copiato nell'\textit{effective set};
1005 \item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno
1006 cancellate dall'\textit{effective set} del processo tutte le capacità
1007 attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
1008 \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
1009 \const{CAP\_MAC\_OVERRIDE}, \const{CAP\_CHOWN}, \const{CAP\_FSETID} e
1010 \const{CAP\_FOWNER} (le prime due a partire dal kernel 2.2.30), nella
1011 transizione inversa verranno invece inserite nell'\textit{effective set}
1012 quelle capacità della precedente lista che sono presenti nel suo
1013 \textit{permitted set}.
1014 \item se come risultato di una transizione riguardante gli identificativi dei
1015 gruppi \textit{real}, \textit{saved} ed \textit{effective} in cui si passa
1016 da una situazione in cui uno di questi era nullo ad una in cui sono tutti
1017 non nulli,\footnote{in sostanza questo è il caso di quando si chiama
1018 \func{setuid} per rimuovere definitivamente i privilegi di amministratore
1019 da un processo.} verranno azzerati completamente sia il \textit{permitted
1020 set} che l'\textit{effective set}.
1022 \label{sec:capability-uid-transition}
1024 La combinazione di tutte queste regole consente di riprodurre il comportamento
1025 ordinario di un sistema di tipo Unix tradizionale, ma può risultare
1026 problematica qualora si voglia passare ad una configurazione di sistema
1027 totalmente basata sull'applicazione delle \textit{capabilities}; in tal caso
1028 infatti basta ad esempio eseguire un programma con \acr{suid} bit di proprietà
1029 dell'amministratore per far riottenere ad un processo tutte le capacità
1030 presenti nel suo \textit{bounding set}, anche se si era avuta la cura di
1031 cancellarle dal \textit{permitted set}.
1033 \itindbeg{securebits}
1035 Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
1036 capabilities} sono abilitate, ad ogni processo viene stata associata una
1037 ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
1038 mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
1039 valore consente di modificare queste regole speciali che si applicano ai
1040 processi con \ids{UID} nullo. La maschera viene sempre mantenuta
1041 attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
1042 cancellato il flag \const{SECURE\_KEEP\_CAPS}.
1047 \begin{tabular}{|l|p{10cm}|}
1049 \textbf{Flag} & \textbf{Descrizione} \\
1052 \constd{SECURE\_KEEP\_CAPS}&Il processo non subisce la cancellazione delle
1053 sue \textit{capabilities} quando tutti i suoi
1054 \ids{UID} passano ad un valore non
1055 nullo (regola di compatibilità per il cambio
1056 di \ids{UID} n.~3 del precedente
1057 elenco), sostituisce il precedente uso
1058 dell'operazione \const{PR\_SET\_KEEPCAPS} di
1060 \constd{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
1061 delle sue \textit{capabilities} nel passaggio
1062 da nullo a non nullo degli \ids{UID}
1063 dei gruppi \textit{effective} e
1064 \textit{file system} (regole di compatibilità
1065 per il cambio di \ids{UID} nn.~1 e 2 del
1066 precedente elenco).\\
1067 \constd{SECURE\_NOROOT} & Il processo non assume nessuna capacità
1068 aggiuntiva quando esegue un programma, anche
1069 se ha \ids{UID} nullo o il programma ha
1070 il \acr{suid} bit attivo ed appartiene
1071 all'amministratore (regola di compatibilità
1072 per l'esecuzione di programmi senza
1073 \textit{capabilities}).\\
1076 \caption{Costanti identificative dei flag che compongono la maschera dei
1077 \textit{securebits}.}
1078 \label{tab:securebits_values}
1081 A ciascuno dei flag di tab.~\ref{tab:securebits_values} è inoltre abbinato un
1082 corrispondente flag di blocco, identificato da una costante omonima con
1083 l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha
1084 l'effetto di rendere permanente l'impostazione corrente del corrispondente
1085 flag ordinario; in sostanza con \constd{SECURE\_KEEP\_CAPS\_LOCKED} si rende
1086 non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con
1087 \constd{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
1088 \const{SECURE\_NO\_SETUID\_FIXUP} e con \constd{SECURE\_NOROOT\_LOCKED} per
1089 \const{SECURE\_NOROOT}.
1091 Per l'impostazione di questi flag sono state predisposte due specifiche
1092 operazioni di \func{prctl} (vedi sez.~\ref{sec:process_prctl}),
1093 \const{PR\_GET\_SECUREBITS}, che consente di ottenerne il valore, e
1094 \const{PR\_SET\_SECUREBITS}, che consente di modificarne il valore; per
1095 quest'ultima sono comunque necessari i privilegi di amministratore ed in
1096 particolare la capacità \const{CAP\_SETPCAP}. Prima dell'introduzione dei
1097 \textit{securebits} era comunque possibile ottenere lo stesso effetto di
1098 \const{SECURE\_KEEP\_CAPS} attraverso l'uso di un'altra operazione di
1099 \func{prctl}, \const{PR\_SET\_KEEPCAPS}.
1101 \itindend{securebits}
1103 Oltre alla gestione dei \textit{securebits} la nuova versione delle
1104 \textit{file capabilities} prevede l'uso di \func{prctl} anche per la gestione
1105 del \textit{capabilities bounding set}, attraverso altre due operazioni
1106 dedicate, \const{PR\_CAPBSET\_READ} per controllarne il valore e
1107 \const{PR\_CAPBSET\_DROP} per modificarlo; quest'ultima di nuovo è una
1108 operazione privilegiata che richiede la capacità \const{CAP\_SETPCAP} e che,
1109 come indica chiaramente il nome, permette solo la rimozione di una
1110 \textit{capability} dall'insieme; per i dettagli sull'uso di tutte queste
1111 operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}.
1113 \itindend{file~capabilities}
1116 % NOTE per dati relativi al process capability bounding set, vedi:
1117 % http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
1119 % NOTE riferimenti ai vari cambiamenti vedi:
1120 % http://lwn.net/Articles/280279/
1121 % http://lwn.net/Articles/256519/
1122 % http://lwn.net/Articles/211883/
1125 Un elenco delle \textit{capabilities} disponibili su Linux, con una breve
1126 descrizione ed il nome delle costanti che le identificano, è riportato in
1127 tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa tabella,
1128 ripreso dalla pagina di manuale (accessibile con \texttt{man capabilities})
1129 e dalle definizioni in \texttt{include/linux/capabilities.h}, è aggiornato
1130 al kernel 3.2.} la tabella è divisa in due parti, la prima riporta le
1131 \textit{capabilities} previste anche nella bozza dello standard POSIX1.e, la
1132 seconda quelle specifiche di Linux. Come si può notare dalla tabella alcune
1133 \textit{capabilities} attengono a singole funzionalità e sono molto
1134 specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
1135 opportuno dettagliare maggiormente.
1137 \begin{table}[!h!btp]
1140 \begin{tabular}{|l|p{10cm}|}
1142 \textbf{Capacità}&\textbf{Descrizione}\\
1146 % POSIX-draft defined capabilities.
1148 \constd{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
1149 controllo dell'auditing (dal kernel 2.6.11).\\
1150 \constd{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
1151 auditing del kernel (dal kernel 2.6.11).\\
1152 % TODO verificare questa roba dell'auditing
1153 \constd{CAP\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare
1154 la sospensione del sistema (dal kernel 3.5).\\
1155 \constd{CAP\_CHOWN} & Cambiare proprietario e gruppo
1156 proprietario di un file (vedi
1157 sez.~\ref{sec:file_ownership_management}).\\
1158 \constd{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
1159 permessi di lettura, scrittura ed esecuzione dei
1160 file, (vedi sez.~\ref{sec:file_access_control}).\\
1161 \constd{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
1162 permessi di lettura ed esecuzione per
1164 sez.~\ref{sec:file_access_control}).\\
1165 \const{CAP\_FOWNER} & Evitare il controllo della proprietà di un file
1166 per tutte le operazioni privilegiate non coperte
1167 dalle precedenti \const{CAP\_DAC\_OVERRIDE} e
1168 \const{CAP\_DAC\_READ\_SEARCH}.\\
1169 \constd{CAP\_FSETID} & Evitare la cancellazione automatica dei bit
1170 \acr{suid} e \acr{sgid} quando un file
1171 per i quali sono impostati viene modificato da
1172 un processo senza questa capacità e la capacità
1173 di impostare il bit \acr{sgid} su un file anche
1174 quando questo è relativo ad un gruppo cui non si
1176 sez.~\ref{sec:file_perm_management}).\\
1177 \constd{CAP\_KILL} & Mandare segnali a qualunque
1178 processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
1179 \constd{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file
1180 (dal kernel 2.6.24).\\
1181 \constd{CAP\_SETGID} & Manipolare i group ID dei
1182 processi, sia il principale che i supplementari,
1183 (vedi sez.~\ref{sec:proc_setgroups}) che quelli
1184 trasmessi tramite i socket \textit{unix domain}
1185 (vedi sez.~\ref{sec:unix_socket}).\\
1186 \constd{CAP\_SETUID} & Manipolare gli user ID del
1187 processo (vedi sez.~\ref{sec:proc_setuid}) e di
1188 trasmettere un user ID arbitrario nel passaggio
1189 delle credenziali coi socket \textit{unix
1190 domain} (vedi sez.~\ref{sec:unix_socket}).\\
1192 % Linux specific capabilities
1195 \constd{CAP\_IPC\_LOCK} & Effettuare il \textit{memory locking} con le
1196 funzioni \func{mlock}, \func{mlockall},
1197 \func{shmctl}, \func{mmap} (vedi
1198 sez.~\ref{sec:proc_mem_lock} e
1199 sez.~\ref{sec:file_memory_map}). \\
1200 % TODO verificare l'interazione con SHM_HUGETLB
1201 \constd{CAP\_IPC\_OWNER}& Evitare il controllo dei permessi
1202 per le operazioni sugli oggetti di
1203 intercomunicazione fra processi (vedi
1204 sez.~\ref{sec:ipc_sysv}).\\
1205 \constd{CAP\_LEASE} & Creare dei \textit{file lease} (vedi
1206 sez.~\ref{sec:file_asyncronous_lease})
1207 pur non essendo proprietari del file (dal kernel
1209 \constd{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
1210 \textit{immutable} e \textit{append-only} (vedi
1211 sez.~\ref{sec:file_perm_overview}) se
1213 \constd{CAP\_MAC\_ADMIN}& Amministrare il \textit{Mandatory
1214 Access Control} di \textit{Smack} (dal kernel
1216 \constd{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
1217 Access Control} di \textit{Smack} (dal kernel
1219 \constd{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
1220 sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
1221 \const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
1222 privilegiate sulla rete.\\
1223 \constd{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
1224 sez.~\ref{sec:TCP_func_bind}).\\
1225 \constd{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
1226 \textit{broadcast} e \textit{multicast}.\\
1227 \constd{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
1228 (vedi sez.~\ref{sec:sock_type}).\\
1229 \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
1230 \textit{capabilities}.\\
1231 \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti amministrativi.\\
1232 \constd{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
1233 sez.~\ref{sec:sys_reboot}).\\
1234 \constd{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
1235 sez.~\ref{sec:file_chroot}).\\
1236 \constd{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
1237 \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi
1238 sez.~\ref{sec:proc_priority}).\\
1239 \constd{CAP\_SYS\_PACCT}& Usare le funzioni di \textit{accounting} dei
1241 sez.~\ref{sec:sys_bsd_accounting}).\\
1242 \constd{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
1244 sez.~\ref{sec:process_ptrace}).\\
1245 \constd{CAP\_SYS\_RAWIO}& Operare sulle porte di I/O con \func{ioperm} e
1247 sez.~\ref{sec:process_io_port}).\\
1248 \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni sulle risorse.\\
1249 \constd{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
1250 sez.~\ref{sec:sys_time}).\\
1251 \constd{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
1252 con la funzione \func{vhangup}.\\
1253 \constd{CAP\_SYSLOG} & Gestire il buffer dei messaggi
1254 del kernel, (vedi sez.~\ref{sec:sess_daemon}),
1255 introdotta dal kernel 2.6.38 come capacità
1256 separata da \const{CAP\_SYS\_ADMIN}.\\
1257 \constd{CAP\_WAKE\_ALARM}&Usare i timer di tipo
1258 \const{CLOCK\_BOOTTIME\_ALARM} e
1259 \const{CLOCK\_REALTIME\_ALARM}, vedi
1260 sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
1263 \caption{Le costanti che identificano le \textit{capabilities} presenti nel
1265 \label{tab:proc_capabilities}
1268 \constbeg{CAP\_SETPCAP}
1270 Prima di dettagliare il significato della capacità più generiche, conviene
1271 però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
1272 stato completamente cambiato con l'introduzione delle \textit{file
1273 capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
1274 che permetteva al processo che la possedeva di impostare o rimuovere le
1275 \textit{capabilities} presenti nel suo \textit{permitted set} su un qualunque
1276 altro processo. In realtà questo non è mai stato l'uso inteso nelle bozze
1277 dallo standard POSIX, ed inoltre, come si è già accennato, dato che questa
1278 capacità è sempre stata assente (a meno di specifiche ricompilazioni del
1279 kernel) nel \textit{capabilities bounding set} usato di default, essa non è
1280 neanche mai stata realmente disponibile.
1282 Con l'introduzione \textit{file capabilities} e il cambiamento del significato
1283 del \textit{capabilities bounding set} la possibilità di modificare le
1284 capacità di altri processi è stata completamente rimossa, e
1285 \const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
1286 significato originario, e cioè la capacità del processo di poter inserire nel
1287 suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
1288 set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
1289 processo di eliminare una capacità dal proprio \textit{bounding set} (con la
1290 conseguente impossibilità successiva di eseguire programmi con quella
1291 capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
1293 \constend{CAP\_SETPCAP}
1294 \constbeg{CAP\_FOWNER}
1296 La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
1297 maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
1298 processo che non ha la proprietà di un file in un vasto campo di
1299 operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del
1300 processo (o meglio l'\ids{UID} di filesystem, vedi
1301 sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste
1302 comprendono i cambiamenti dei permessi e dei tempi del file (vedi
1303 sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
1304 impostazioni degli attributi dei file e delle ACL (vedi
1305 sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
1306 \textit{sticky bit} nella cancellazione dei file (vedi
1307 sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
1308 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
1309 sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl_ioctl}) senza
1312 \constend{CAP\_FOWNER}
1313 \constbeg{CAP\_NET\_ADMIN}
1315 Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
1316 la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
1317 privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
1318 il \textit{multicasting} (vedi sez.\ref{sec:sock_ipv4_options}), eseguire la
1319 configurazione delle interfacce di rete (vedi
1320 sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la tabella di instradamento.
1322 \constend{CAP\_NET\_ADMIN}
1323 \constbeg{CAP\_SYS\_ADMIN}
1325 Una terza \textit{capability} con vasto campo di applicazione è
1326 \const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
1327 come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
1328 disattivare la \textit{swap}, montare, rimontare e smontare filesystem (vedi
1329 sez.~\ref{sec:filesystem_mounting}), effettuare operazioni di controllo su
1330 qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
1331 sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
1332 (vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella
1333 trasmissione delle credenziali dei socket (vedi
1334 sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
1335 (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
1336 \const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
1337 sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
1338 di file aperti,\footnote{quello indicato da \sysctlfiled{fs/file-max}.}
1339 effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
1340 sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
1341 usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
1342 sez.~\ref{sec:process_clone}).
1344 \constend{CAP\_SYS\_ADMIN}
1345 \constbeg{CAP\_SYS\_NICE}
1347 Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
1348 aumentare le priorità di esecuzione dei processi, come la diminuzione del
1349 valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
1350 priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
1351 l'impostazione delle affinità di processore (vedi
1352 sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
1353 anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
1354 alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
1355 arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
1356 politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
1358 \constend{CAP\_SYS\_NICE}
1359 \constbeg{CAP\_SYS\_RESOURCE}
1361 Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
1362 possibilità di superare i limiti imposti sulle risorse di sistema, come usare
1363 lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
1364 usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
1365 filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
1366 risorse di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul
1367 numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
1368 SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
1370 \constend{CAP\_SYS\_RESOURCE}
1372 Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
1373 funzioni che permettono rispettivamente di leggere ed impostare i valori dei
1374 tre insiemi illustrati in precedenza. Queste due funzioni di sistema sono
1375 \funcd{capget} e \funcd{capset} e costituiscono l'interfaccia di gestione
1376 basso livello; i loro rispettivi prototipi sono:
1379 \fhead{sys/capability.h}
1380 \fdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
1381 \fdesc{Legge le \textit{capabilities}.}
1382 \fdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t datap)}
1383 \fdesc{Imposta le \textit{capabilities}.}
1386 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
1387 caso \var{errno} assumerà uno dei valori:
1389 \item[\errcode{EFAULT}] si è indicato un puntatore sbagliato o nullo
1390 per \param{hdrp} o \param{datap} (quest'ultimo può essere nullo solo se si
1391 usa \func{capget} per ottenere la versione delle \textit{capabilities}
1393 \item[\errcode{EINVAL}] si è specificato un valore non valido per uno dei
1394 campi di \param{hdrp}, in particolare una versione non valida della
1395 versione delle \textit{capabilities}.
1396 \item[\errcode{EPERM}] si è tentato di aggiungere una capacità nell'insieme
1397 delle \textit{capabilities} permesse, o di impostare una capacità non
1398 presente nell'insieme di quelle permesse negli insieme delle effettive o
1399 ereditate, o si è cercato di impostare una \textit{capability} di un altro
1400 processo senza avare \const{CAP\_SETPCAP}.
1401 \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
1406 Queste due funzioni prendono come argomenti due tipi di dati dedicati,
1407 definiti come puntatori a due strutture specifiche di Linux, illustrate in
1408 fig.~\ref{fig:cap_kernel_struct}. Per un certo periodo di tempo era anche
1409 indicato che per poterle utilizzare fosse necessario che la macro
1410 \macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
1411 una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
1412 \headfiled{sys/capability.h}) requisito che non risulta più
1413 presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
1416 \begin{figure}[!htb]
1419 \begin{minipage}[c]{0.8\textwidth}
1420 \includestruct{listati/cap_user_header_t.h}
1423 \caption{Definizione delle strutture a cui fanno riferimento i puntatori
1424 \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
1425 l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
1426 \label{fig:cap_kernel_struct}
1429 Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
1430 prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
1431 essere modificate con il cambiamento del kernel (in particolare i tipi di dati
1432 delle strutture) ed anche se finora l'interfaccia è risultata stabile, non c'è
1433 nessuna assicurazione che questa venga mantenuta,\footnote{viene però
1434 garantito che le vecchie funzioni continuino a funzionare.} Pertanto se si
1435 vogliono scrivere programmi portabili che possano essere eseguiti senza
1436 modifiche o adeguamenti su qualunque versione del kernel è opportuno
1437 utilizzare le interfacce di alto livello che vedremo più avanti.
1439 La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
1440 tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono
1441 leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
1442 usano le \textit{file capabilities}, può essere solo 0 o il \ids{PID} del
1443 processo chiamante, che sono equivalenti. Non tratteremo, essendo comunque di
1444 uso irrilevante, il caso in cui, in mancanza di tale supporto, la funzione può
1445 essere usata per modificare le \textit{capabilities} di altri processi, per il
1446 quale si rimanda, se interessati, alla lettura della pagina di manuale.
1448 Il campo \var{version} deve essere impostato al valore della versione delle
1449 stesse usata dal kernel (quello indicato da una delle costanti
1450 \texttt{\_LINUX\_CAPABILITY\_VERSION\_n} di fig.~\ref{fig:cap_kernel_struct})
1451 altrimenti le funzioni ritorneranno con un errore di \errcode{EINVAL},
1452 restituendo nel campo stesso il valore corretto della versione in uso. La
1453 versione due è comunque deprecata e non deve essere usata, ed il kernel
1454 stamperà un avviso se lo si fa.
1456 I valori delle \textit{capabilities} devono essere passati come maschere
1457 binarie;\footnote{e si tenga presente che i valori di
1458 tab.~\ref{tab:proc_capabilities} non possono essere combinati direttamente,
1459 indicando il numero progressivo del bit associato alla relativa capacità.}
1460 con l'introduzione delle \textit{capabilities} a 64 bit inoltre il
1461 puntatore \param{datap} non può essere più considerato come relativo ad una
1462 singola struttura, ma ad un vettore di due strutture.\footnote{è questo cambio
1463 di significato che ha portato a deprecare la versione 2, che con
1464 \func{capget} poteva portare ad un buffer overflow per vecchie applicazioni
1465 che continuavano a considerare \param{datap} come puntatore ad una singola
1468 Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
1469 garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
1470 gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
1471 questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
1472 dello standard POSIX.1e, non fanno parte della \acr{glibc} e sono fornite in
1473 una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
1474 Debian può essere installata con il pacchetto omonimo.} pertanto se un
1475 programma le utilizza si dovrà indicare esplicitamente al compilatore l'uso
1476 della suddetta libreria attraverso l'opzione \texttt{-lcap}.
1478 \itindbeg{capability~state}
1480 Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
1481 dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
1482 \typed{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
1483 \textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
1484 una struttura interna utilizzata dalle librerie, i cui campi non devono mai
1485 essere acceduti direttamente.} in sono memorizzati tutti i dati delle
1486 \textit{capabilities}.
1488 In questo modo è possibile mascherare i dettagli della gestione di basso
1489 livello, che potranno essere modificati senza dover cambiare le funzioni
1490 dell'interfaccia, che fanno riferimento soltanto ad oggetti di questo tipo.
1491 L'interfaccia pertanto non soltanto fornisce le funzioni per modificare e
1492 leggere le \textit{capabilities}, ma anche quelle per gestire i dati
1493 attraverso i \textit{capability state}, che presentano notevoli affinità,
1494 essendo parte di bozze dello stesso standard, con quelle già viste per le ACL.
1496 La prima funzione dell'interfaccia è quella che permette di inizializzare un
1497 \textit{capability state}, allocando al contempo la memoria necessaria per i
1498 relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
1501 \fhead{sys/capability.h}
1502 \fdecl{cap\_t cap\_init(void)}
1503 \fdesc{Crea ed inizializza un \textit{capability state}.}
1506 {La funzione ritorna un \textit{capability state} in caso di successo e
1507 \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
1508 valore \errval{ENOMEM}. }
1511 La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
1512 con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
1513 non c'è memoria sufficiente ad allocare i dati) viene restituito \val{NULL}
1514 ed \var{errno} viene impostata a \errval{ENOMEM}.
1516 La memoria necessaria a mantenere i dati viene automaticamente allocata da
1517 \func{cap\_init}, ma dovrà essere disallocata esplicitamente quando non è più
1518 necessaria utilizzando, per questo l'interfaccia fornisce una apposita
1519 funzione, \funcd{cap\_free}, il cui prototipo è:
1522 \fhead{sys/capability.h}
1523 \fdecl{int cap\_free(void *obj\_d)}
1524 \fdesc{Disalloca la memoria allocata per i dati delle \textit{capabilities}..}
1527 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1528 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
1533 La funzione permette di liberare la memoria allocata dalle altre funzioni
1534 della libreria sia per un \textit{capability state}, nel qual caso l'argomento
1535 sarà un dato di tipo \type{cap\_t}, che per una descrizione testuale dello
1536 stesso,\footnote{cioè quanto ottenuto tramite la funzione
1537 \func{cap\_to\_text}.} nel qual caso l'argomento sarà un dato di tipo
1538 \texttt{char *}. Per questo motivo l'argomento \param{obj\_d} è dichiarato
1539 come \texttt{void *}, per evitare la necessità di eseguire un \textit{cast},
1540 ma dovrà comunque corrispondere ad un puntatore ottenuto tramite le altre
1541 funzioni della libreria, altrimenti la funzione fallirà con un errore di
1544 Infine si può creare una copia di un \textit{capability state} ottenuto in
1545 precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
1548 \fhead{sys/capability.h}
1549 \fdecl{cap\_t cap\_dup(cap\_t cap\_p)}
1550 \fdesc{Duplica un \textit{capability state} restituendone una copia.}
1553 {La funzione ritorna un \textit{capability state} in caso di successo e
1554 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1555 \errval{ENOMEM} o \errval{EINVAL} nel loro significato generico.}
1559 La funzione crea una copia del \textit{capability state} posto all'indirizzo
1560 \param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
1561 copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
1562 nell'originale. La memoria necessaria viene allocata automaticamente dalla
1563 funzione. Una volta effettuata la copia i due \textit{capability state}
1564 potranno essere modificati in maniera completamente indipendente, ed alla fine
1565 delle operazioni si dovrà disallocare anche la copia, oltre all'originale.
1567 Una seconda classe di funzioni di servizio previste dall'interfaccia sono
1568 quelle per la gestione dei dati contenuti all'interno di un \textit{capability
1569 state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
1572 \fhead{sys/capability.h}
1573 \fdecl{int cap\_clear(cap\_t cap\_p)}
1574 \fdesc{Inizializza un \textit{capability state} cancellando tutte le
1575 \textit{capabilities}.}
1578 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1579 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
1583 La funzione si limita ad azzerare tutte le \textit{capabilities} presenti nel
1584 \textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
1585 restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
1586 creazione con \func{cap\_init}.
1588 Una variante di \func{cap\_clear} è \funcd{cap\_clear\_flag} che cancella da
1589 un \textit{capability state} tutte le \textit{capabilities} di un certo
1590 insieme fra quelli elencati a pag.~\pageref{sec:capabilities_set}, il suo
1594 \fhead{sys/capability.h}
1595 \fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
1596 \fdesc{Cancella delle \textit{capabilities} da un \textit{capability state}.}
1599 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1600 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
1604 La funzione richiede che si indichi quale degli insiemi si intente cancellare
1605 da \param{cap\_p} con l'argomento \param{flag}. Questo deve essere specificato
1606 con una variabile di tipo \type{cap\_flag\_t} che può assumere
1607 esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
1608 verificare dalla sua definizione che si trova in
1609 \headfile{sys/capability.h}.} uno dei valori illustrati in
1610 tab.~\ref{tab:cap_set_identifier}.
1615 \begin{tabular}[c]{|l|l|}
1617 \textbf{Valore} & \textbf{Significato} \\
1620 \constd{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
1621 \constd{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
1622 \constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
1625 \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
1626 identifica gli insiemi delle \textit{capabilities}.}
1627 \label{tab:cap_set_identifier}
1630 Si possono inoltre confrontare in maniera diretta due diversi
1631 \textit{capability state} con la funzione \funcd{cap\_compare}; il suo
1635 \fhead{sys/capability.h}
1636 \fdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
1637 \fdesc{Confronta due \textit{capability state}.}
1640 {La funzione ritorna $0$ se i \textit{capability state} sono identici
1641 ed un valore positivo se differiscono, non sono previsti errori.}
1645 La funzione esegue un confronto fra i due \textit{capability state} passati
1646 come argomenti e ritorna in un valore intero il risultato, questo è nullo se
1647 sono identici o positivo se vi sono delle differenze. Il valore di ritorno
1648 della funzione consente inoltre di per ottenere ulteriori informazioni su
1649 quali sono gli insiemi di \textit{capabilities} che risultano differenti. Per
1650 questo si può infatti usare la apposita macro \macro{CAP\_DIFFERS}:
1655 \fhead{sys/capability.h}
1656 \fdecl{int \macrod{CAP\_DIFFERS}(value, flag)}
1657 \fdesc{Controlla lo stato di eventuali differenze delle \textit{capabilities}
1658 nell'insieme \texttt{flag}.}
1663 La macro richiede che si passi nell'argomento \texttt{value} il risultato
1664 della funzione \func{cap\_compare} e in \texttt{flag} l'indicazione (coi
1665 valori di tab.~\ref{tab:cap_set_identifier}) dell'insieme che si intende
1666 controllare; restituirà un valore diverso da zero se le differenze rilevate da
1667 \func{cap\_compare} sono presenti nell'insieme indicato.
1669 Per la gestione dei singoli valori delle \textit{capabilities} presenti in un
1670 \textit{capability state} l'interfaccia prevede due funzioni specifiche,
1671 \funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
1672 rispettivamente di leggere o impostare il valore di una capacità all'interno
1673 in uno dei tre insiemi già citati; i rispettivi prototipi sono:
1676 \fhead{sys/capability.h}
1677 \fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
1679 \phantom{int cap\_get\_flag(}cap\_flag\_value\_t *value\_p)}
1680 \fdesc{Legge il valore di una \textit{capability}.}
1681 \fdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
1682 cap\_value\_t *caps, \\
1683 \phantom{int cap\_set\_flag(}cap\_flag\_value\_t value)}
1684 \fdesc{Imposta il valore di una \textit{capability}.}
1687 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
1688 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
1692 In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
1693 \textit{capability state} su cui operare, mentre l'argomento \param{flag}
1694 indica su quale dei tre insiemi si intende operare, sempre con i valori di
1695 tab.~\ref{tab:cap_set_identifier}. La capacità che si intende controllare o
1696 impostare invece deve essere specificata attraverso una variabile di tipo
1697 \typed{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
1698 riportati in tab.~\ref{tab:proc_capabilities}, in questo caso però non è
1699 possibile combinare diversi valori in una maschera binaria, una variabile di
1700 tipo \type{cap\_value\_t} può indicare una sola capacità.\footnote{in
1701 \headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
1702 \ctyp{int}, ma i valori validi sono soltanto quelli di
1703 tab.~\ref{tab:proc_capabilities}.}
1705 Infine lo stato di una capacità è descritto ad una variabile di tipo
1706 \type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
1707 uno\footnote{anche questo è un tipo enumerato.} dei valori di
1708 tab.~\ref{tab:cap_value_type}.
1713 \begin{tabular}[c]{|l|l|}
1715 \textbf{Valore} & \textbf{Significato} \\
1718 \constd{CAP\_CLEAR}& La capacità non è impostata.\\
1719 \constd{CAP\_SET} & La capacità è impostata.\\
1722 \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
1723 indica lo stato di una capacità.}
1724 \label{tab:cap_value_type}
1727 La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
1728 dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
1729 \param{flag} e lo restituisce come \textit{value result argument} nella
1730 variabile puntata dall'argomento \param{value\_p}. Questa deve essere di tipo
1731 \type{cap\_flag\_value\_t} ed assumerà uno dei valori di
1732 tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
1733 lo stato di una capacità alla volta.
1735 La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
1736 più \textit{capabilities}, anche se solo all'interno dello stesso insieme ed
1737 allo stesso valore. Per questo motivo essa prende un vettore di valori di tipo
1738 \type{cap\_value\_t} nell'argomento \param{caps}, la cui dimensione viene
1739 specificata dall'argomento \param{ncap}. Il tipo di impostazione da eseguire
1740 (cancellazione o attivazione) per le capacità elencate in \param{caps} viene
1741 indicato dall'argomento \param{value} sempre con i valori di
1742 tab.~\ref{tab:cap_value_type}.
1744 Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede
1745 che sia possibile utilizzare anche una rappresentazione testuale del contenuto
1746 di un \textit{capability state} e fornisce le opportune funzioni di
1747 gestione;\footnote{entrambe erano previste dalla bozza dello standard
1748 POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione
1749 testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
1752 \fhead{sys/capability.h}
1753 \fdecl{char *cap\_to\_text(cap\_t caps, ssize\_t *length\_p)}
1754 \fdesc{Genera una visualizzazione testuale delle \textit{capabilities}.}
1757 {La funzione ritorna un puntatore alla stringa con la descrizione delle
1758 \textit{capabilities} in caso di successo e \val{NULL} per un errore, nel
1759 qual caso \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM}
1760 nel loro significato generico.}
1763 La funzione ritorna l'indirizzo di una stringa contente la descrizione
1764 testuale del contenuto del \textit{capability state} \param{caps} passato come
1765 argomento, e, qualora l'argomento \param{length\_p} sia diverso da \val{NULL},
1766 restituisce come \textit{value result argument} nella variabile intera da
1767 questo puntata la lunghezza della stringa. La stringa restituita viene
1768 allocata automaticamente dalla funzione e pertanto dovrà essere liberata con
1771 La rappresentazione testuale, che viene usata anche dai programmi di gestione a
1772 riga di comando, prevede che lo stato venga rappresentato con una stringa di
1773 testo composta da una serie di proposizioni separate da spazi, ciascuna delle
1774 quali specifica una operazione da eseguire per creare lo stato finale. Nella
1775 rappresentazione si fa sempre conto di partire da uno stato in cui tutti gli
1776 insiemi sono vuoti e si provvede a impostarne i contenuti.
1778 Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i
1779 nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un
1780 operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I
1781 nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene
1782 inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a
1783 scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
1784 iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
1785 l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
1786 essere sempre minuscole, e se ne può indicare più di uno.
1788 Gli operatori possibili sono solo tre: ``\texttt{+}'' che aggiunge le capacità
1789 elencate agli insiemi indicati, ``\texttt{-}'' che le toglie e ``\texttt{=}''
1790 che le assegna esattamente. I primi due richiedono che sia sempre indicato sia
1791 un elenco di capacità che gli insiemi a cui esse devono applicarsi, e
1792 rispettivamente attiveranno o disattiveranno le capacità elencate nell'insieme
1793 o negli insiemi specificati, ignorando tutto il resto. I due operatori possono
1794 anche essere combinati nella stessa proposizione, per aggiungere e togliere le
1795 capacità dell'elenco da insiemi diversi.
1797 L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
1798 pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
1799 di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
1800 specificati, questo significa che in genere lo si usa una sola volta
1801 all'inizio della stringa. In tal caso l'elenco delle capacità può non essere
1802 indicato e viene assunto che si stia facendo riferimento a tutte quante senza
1803 doverlo scrivere esplicitamente.
1805 Come esempi avremo allora che un processo non privilegiato di un utente, che
1806 non ha nessuna capacità attiva, avrà una rappresentazione nella forma
1807 ``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a
1808 nessun insieme (vale la cancellazione preventiva), mentre un processo con
1809 privilegi di amministratore avrà una rappresentazione nella forma
1810 ``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi
1811 \textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato
1812 in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
1813 capacità verranno comunque attivate attraverso una \func{exec}). Infine, come
1814 esempio meno banale dei precedenti, otterremo per \texttt{init} una
1815 rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come
1816 accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
1819 Viceversa per ottenere un \textit{capability state} dalla sua rappresentazione
1820 testuale si può usare la funzione \funcd{cap\_from\_text}, il cui prototipo è:
1823 \fhead{sys/capability.h}
1824 \fdecl{cap\_t cap\_from\_text(const char *string)}
1825 \fdesc{Crea un \textit{capability state} dalla sua rappresentazione testuale.}
1828 {La funzione ritorna un \textit{capability state} in caso di successo e
1829 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1830 \errval{EINVAL} o \errval{ENOMEM} nel loro significato generico.}
1834 La funzione restituisce il puntatore ad un \textit{capability state}
1835 inizializzato con i valori indicati nella stringa \param{string} che ne
1836 contiene la rappresentazione testuale. La memoria per il \textit{capability
1837 state} viene allocata automaticamente dalla funzione e dovrà essere liberata
1838 con \func{cap\_free}.
1840 Alle due funzioni citate se ne aggiungono altre due che consentono di
1841 convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
1842 stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
1843 \funcd{cap\_to\_name} e \funcd{cap\_from\_name}, sono estensioni specifiche di
1844 Linux ed i rispettivi prototipi sono:
1847 \fhead{sys/capability.h}
1848 \fdecl{char *cap\_to\_name(cap\_value\_t cap)}
1849 \fdesc{Converte il valore numerico di una \textit{capabilities} alla sua
1850 rappresentazione testuale.}
1851 \fdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
1853 \fdesc{Converte la rappresentazione testuale di una \textit{capabilities} al
1854 suo valore numerico.}
1857 {La funzione \func{cap\_to\_name} ritorna un puntatore ad una stringa in caso
1858 di successo e \val{NULL} per un errore, mentre \func{cap\_to\_name} ritorna
1859 $0$ in caso di successo e $-1$ per un errore, per entrambe in caso di errore
1860 \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM} nel loro
1861 significato generico.
1865 La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
1866 essere liberata con \func{cap\_free}) che corrisponde al valore della
1867 capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
1868 da \param{cap\_p}, come \textit{value result argument}, il valore della
1869 capacità rappresentata dalla stringa \param{name}.
1871 Fin quei abbiamo trattato solo le funzioni di servizio relative alla
1872 manipolazione dei \textit{capability state} come strutture di dati;
1873 l'interfaccia di gestione prevede però anche le funzioni per trattare le
1874 \textit{capabilities} presenti nei processi. La prima di queste funzioni è
1875 \funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
1876 processo corrente, il suo prototipo è:
1879 \fhead{sys/capability.h}
1880 \fdecl{cap\_t cap\_get\_proc(void)}
1881 \fdesc{Legge le \textit{capabilities} del processo corrente.}
1884 {La funzione ritorna un \textit{capability state} in caso di successo e
1885 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1886 \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM} nel loro significato
1890 La funzione legge il valore delle \textit{capabilities} associate al processo
1891 da cui viene invocata, restituendo il risultato tramite il puntatore ad un
1892 \textit{capability state} contenente tutti i dati che provvede ad allocare
1893 autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
1894 non sarà più utilizzato.
1896 Se invece si vogliono leggere le \textit{capabilities} di un processo
1897 specifico occorre usare la funzione \funcd{cap\_get\_pid}, il cui
1898 prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
1899 prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
1900 ma il valore di ritorno è intero, come si può verificare anche dalla
1901 dichiarazione della stessa in \headfile{sys/capability.h}.} è:
1904 \fhead{sys/capability.h}
1905 \fdecl{cap\_t cap\_get\_pid(pid\_t pid)}
1906 \fdesc{Legge le \textit{capabilities} di un processo.}
1909 {La funzione ritorna un \textit{capability state} in caso di successo e
1910 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1911 \errval{ESRCH} o \errval{ENOMEM} nel loro significato generico. }
1914 La funzione legge il valore delle \textit{capabilities} del processo indicato
1915 con l'argomento \param{pid}, e restituisce il risultato tramite il puntatore
1916 ad un \textit{capability state} contenente tutti i dati che provvede ad
1917 allocare autonomamente e che al solito deve essere disallocato con
1918 \func{cap\_free}. Qualora il processo indicato non esista si avrà un errore di
1919 \errval{ESRCH}. Gli stessi valori possono essere letti direttamente nel
1920 filesystem \textit{proc}, nei file \texttt{/proc/<pid>/status}; ad esempio per
1921 \texttt{init} si otterrà qualcosa del tipo:
1923 piccardi@hain:~/gapil$ \textbf{cat /proc/1/status}
1925 CapInh: 0000000000000000
1926 CapPrm: 00000000fffffeff
1927 CapEff: 00000000fffffeff
1932 \itindend{capability~state}
1934 Infine per impostare le \textit{capabilities} del processo corrente (nella
1935 bozza dello standard POSIX.1e non esiste una funzione che permetta di cambiare
1936 le \textit{capabilities} di un altro processo) si deve usare la funzione
1937 \funcd{cap\_set\_proc}, il cui prototipo è:
1940 \fhead{sys/capability.h}
1941 \fdecl{int cap\_set\_proc(cap\_t cap\_p)}
1942 \fdesc{Imposta le \textit{capabilities} del processo corrente.}
1945 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1946 caso \var{errno} assumerà i valori:
1948 \item[\errcode{EPERM}] si è cercato di attivare una capacità non permessa.
1949 \end{errlist} ed inoltre \errval{EINVAL} nel suo significato generico.}
1952 La funzione modifica le \textit{capabilities} del processo corrente secondo
1953 quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
1954 possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
1955 impostare capacità non presenti nell'insieme di quelle permesse).
1957 In caso di successo i nuovi valori saranno effettivi al ritorno della
1958 funzione, in caso di fallimento invece lo stato delle capacità resterà
1959 invariato. Si tenga presente che \textsl{tutte} le capacità specificate
1960 tramite \param{cap\_p} devono essere permesse; se anche una sola non lo è la
1961 funzione fallirà, e per quanto appena detto, lo stato delle
1962 \textit{capabilities} non verrà modificato (neanche per le parti eventualmente
1965 Oltre a queste funzioni su Linux sono presenti due ulteriori funzioni,
1966 \funcm{capgetp} e \funcm{capsetp}, che svolgono un compito analogo. Queste
1967 funzioni risalgono alla implementazione iniziale delle \textit{capabilities}
1968 ed in particolare \funcm{capsetp} consentirebbe anche, come possibile in quel
1969 caso, di cambiare le capacità di un altro processo. Le due funzioni oggi sono
1970 deprecate e pertanto eviteremo di trattarle, per chi fosse interessato si
1971 rimanda alla lettura della loro pagina di manuale.
1973 Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
1974 si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
1975 \textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
1976 quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
1977 sono le \textit{capabilities} standard che ottiene un processo lanciato
1978 dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
1979 processo qualunque il cui \ids{PID} viene passato come parametro dell'opzione.
1981 \begin{figure}[!htbp]
1982 \footnotesize \centering
1983 \begin{minipage}[c]{\codesamplewidth}
1984 \includecodesample{listati/getcap.c}
1987 \caption{Corpo principale del programma \texttt{getcap.c}.}
1988 \label{fig:proc_getcap}
1991 La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
1992 e si basa su una condizione sulla variabile \var{pid} che se si è usato
1993 l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
1994 che si è tralasciata) al valore del \ids{PID} del processo di cui si vuole
1995 leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
1996 (\texttt{\small 1-6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
1997 per ottenere lo stato delle capacità del processo, nel secondo (\texttt{\small
1998 7-13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
1999 il valore delle capacità del processo indicato.
2001 Il passo successivo è utilizzare (\texttt{\small 15}) \func{cap\_to\_text} per
2002 tradurre in una stringa lo stato, e poi (\texttt{\small 16}) stamparlo; infine
2003 (\texttt{\small 18-19}) si libera la memoria allocata dalle precedenti
2004 funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
2007 \itindend{capabilities}
2009 % TODO vedi http://lwn.net/Articles/198557/ e
2010 % http://www.madore.org/~david/linux/newcaps/
2015 \subsection{La gestione del \textit{Secure Computing}.}
2016 \label{sec:procadv_seccomp}
2018 \itindbeg{secure~computing~mode}
2020 Il \textit{secure computing mode} è un meccanismo ideato per fornire un
2021 supporto per l'esecuzione di codice esterno non fidato e non verificabile a
2022 scopo di calcolo. L'idea era quella di disporre di una modalità di esecuzione
2023 dei programmi che permettesse di vendere la capacità di calcolo della propria
2024 macchina ad un qualche servizio di calcolo distribuito, senza comprometterne
2025 la sicurezza eseguendo codice non sotto il proprio controllo.
2027 La prima versione del meccanismo è stata introdotta con il kernel
2028 2.6.23,\footnote{e disponibile solo avendo abilitato il supporto nel kernel
2029 con l'opzione di configurazione \texttt{CONFIG\_SECCOMP}.} è molto semplice,
2030 il \textit{secure computing mode} viene attivato con \func{prctl} usando
2031 l'opzione \const{PR\_SET\_SECCOMP}, ed indicando \const{SECCOMP\_MODE\_STRICT}
2032 come valore per \param{arg2} (all'epoca unico valore possibile). Una volta
2033 abilitato in questa modalità (in seguito denominata \textit{strict mode}) il
2034 processo o il \textit{thread} chiamante potrà utilizzare soltanto un insieme
2035 estremamente limitato di \textit{system call}: \func{read}, \func{write},
2036 \func{\_exit} e \funcm{sigreturn}; l'esecuzione di qualsiasi altra
2037 \textit{system call} comporta l'emissione di un \signal{SIGKILL} e conseguente
2038 terminazione immediata del processo.
2040 Si tenga presente che in questo caso, con versioni recenti della \acr{glibc}
2041 (il comportamento è stato introdotto con la 2.3), diventa impossibile usare
2042 anche \func{\_exit} in \textit{strict mode}, in quanto questa funzione viene
2043 intercettata ed al suo posto viene chiamata \func{exit\_group} (vedi
2044 sez.~\ref{sec:pthread_management}) che non è consentita e comporta un
2047 Si tenga presente che, non essendo \func{execve} fra le funzioni permesse, per
2048 poter eseguire un programma terzo essendo in \textit{strict mode} questo dovrà
2049 essere fornito in una forma di codice interpretabile fornito attraverso un
2050 socket o una \textit{pipe}, creati prima di lanciare il processo che eseguirà
2051 il codice non fidato.
2055 % TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
2056 % terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
2057 % Documentation/prctl/seccomp_filter.txt
2058 % vedi anche http://lwn.net/Articles/600250/
2060 % TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
2061 % * Documentation/prctl/seccomp_filter.txt
2062 % * http://lwn.net/Articles/475043/
2064 % TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
2065 % vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
2068 \itindend{secure~computing~mode}
2070 \subsection{Altre funzionalità di sicurezza.}
2071 \label{sec:procadv_security_misc}
2073 Oltre alle funzionalità specifiche esaminate nelle sezioni precedenti, il
2074 kernel supporta una varietà di ulteriori impostazioni di sicurezza,
2075 accessibili nelle maniere più varie, che abbiamo raccolto in questa sezione.
2077 Una serie di modalità di sicurezza sono attivabili a richiesta attraverso
2078 alcune opzioni di controllo attivabili via \func{sysctl} o il filesystem
2079 \texttt{/proc}, un elenco delle stesse e dei loro effetti è il seguente:
2081 \begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
2082 \item[\sysctlrelfiled{fs}{protected\_hardlinks}] Un valore nullo, il default,
2083 mantiene il comportamento standard che non pone restrizioni alla creazione
2084 di \textit{hard link}. Se il valore viene posto ad 1 vengono invece attivate
2085 una serie di restrizioni protettive, denominate
2086 \itindex{protected~hardlinks} \textit{protected hardlinks}, che se non
2087 soddisfatte causano il fallimento di \func{link} con un errore di
2088 \errval{EPERM}. Perché questo non avvenga almeno una delle seguenti
2089 condizioni deve essere soddisfatta:
2091 \item il chiamante deve avere privilegi amministrativi (la
2092 \textit{capability} \const{CAP\_FOWNER}). In caso di utilizzo
2093 dell'\textit{user namespace} oltre a possedere \const{CAP\_FOWNER} è
2094 necessario che l'\ids{UID} del proprietario del file sia mappato nel
2096 \item il \textit{filesystem} \ids{UID} del chiamante (normalmente
2097 equivalente all'\ids{UID} effettivo) deve corrispondere a quello del
2098 proprietario del file a cui si vuole effettuare il collegamento.
2099 \item devono essere soddisfatte tutte le seguenti condizioni:
2101 \item il file è un file ordinario
2102 \item il file non ha il \acr{suid} bit attivo
2103 \item il file non ha lo \acr{sgid} bit attivo ed il permesso di esecuzione
2105 \item il chiamante ha i permessi di lettura e scrittura sul file
2109 In sostanza in questo caso un utente potrà creare un collegamento diretto ad
2110 un altro file solo se ne è il proprietario o se questo è un file ordinario
2111 senza permessi speciali ed a cui ha accesso in lettura e scrittura.
2113 Questa funzionalità fornisce una protezione generica che non inficia l'uso
2114 ordinario di \func{link}, ma rende impraticabili una serie di possibili
2115 abusi della stessa; oltre ad impedire l'uso di un \textit{hard link} come
2116 variante in un attacco di \textit{symlink race} (eludendo i
2117 \textit{protected symlinks} di cui al punto successivo), evita anche che si
2118 possa lasciare un riferimento ad un eventuale programma \acr{suid}
2119 vulnerabile, creando un collegamento diretto allo stesso.
2122 \item[\sysctlrelfiled{fs}{protected\_symlinks}] Un valore nullo, il default,
2123 mantiene il comportamento standard che non pone restrizioni nel seguire i
2124 link simbolici. Se il valore viene posto ad 1 vengono attivate delle
2125 restrizioni protettive, denominate \itindex{protected~symlinks}
2126 \textit{protected symlinks}. Quando vengono attivate una qualunque funzione
2127 che esegua la risoluzione di un \textit{pathname} contenente un link
2128 simbolico non conforme alle restrizioni fallirà con un errore di
2129 \errval{EACCESS}. Per evitare l'errore deve essere soddisfatta una delle
2130 seguenti condizioni:
2132 \item il link non è in una directory con permessi analoghi a \file{/tmp}
2133 (scrivibile a tutti e con lo \textit{sticky bit} attivo);
2134 \item il link è in una directory con permessi analoghi a \file{/tmp} ma è
2135 soddisfatta una delle condizioni seguenti:
2137 \item il link simbolico appartiene al chiamante: il controllo viene fatto
2138 usando il \textit{filesystem} \ids{UID} (che normalmente corrisponde
2139 all'\ids{UID} effettivo).
2140 \item il link simbolico ha lo stesso proprietario della directory.
2144 Questa funzionalità consente di rendere impraticabili alcuni attacchi in cui
2145 si approfitta di una differenza di tempo fra il controllo e l'uso di un
2146 file, ed in particolare quella classe di attacchi viene usualmente chiamati
2147 \textit{symlink attack},\footnote{si tratta di un sottoinsieme di quella
2148 classe di attacchi chiamata genericamente \textit{TOCTTOU}, acronimo
2149 appunto di \textit{Time of check to time of use}.} di cui abbiamo parlato
2150 in sez.~\ref{sec:file_temp_file}.
2152 Un possibile esempio di questo tipo di attacco è quello contro un programma
2153 che viene eseguito per conto di un utente privilegiato (ad esempio un
2154 programma con il \acr{suid} o lo \acr{sgid} bit attivi) che prima controlla
2155 l'esistenza di un file e se non esiste lo crea. Se questa procedura, che è
2156 tipica della creazione di file temporanei sotto \file{/tmp}, non viene
2157 eseguita in maniera corretta,\footnote{ad esempio con le modalità che
2158 abbiamo trattato in sez.~\ref{sec:file_temp_file}, che per quanto note da
2159 tempo continuano ad essere ignorate.} un attaccante ha una finestra di
2160 tempo in cui può creare prima del programma un \textit{link simbolico} ad un
2161 file di sua scelta, compresi file di dispositivo o file a cui non avrebbe
2162 accesso, facendolo poi utilizzare al programma.
2164 Attivando la funzionalità si rende impossibile seguire un link simbolico in
2165 una directory temporanea come \texttt{/tmp}, a meno che questo non sia di
2166 proprietà del chiamante, o che questo non appartenga al proprietario della
2167 directory. Questo impedisce che i link simbolici creati da un attaccante
2168 possano essere seguiti da un programma privilegiato (perché apparterranno
2169 all'attaccante) mentre quelli creati dall'amministratore (che i genere è il
2170 proprietario di \texttt{/tmp}) saranno seguiti comunque.
2175 % TODO: trattare pure protected_regular e protected_fifos introdotti con il
2176 % 4.19 (vedi https://lwn.net/Articles/763106/)
2180 % TODO: trattare keyctl (man 2 keyctl)
2184 % TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
2185 % pkey_mprotect, introdotte con il kernel 4.8, vedi
2186 % http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
2188 %TODO trattare kcmp aggiunta con il kernel 3.5, vedi
2189 % https://lwn.net/Articles/478111/
2192 \section{Funzionalità avanzate e specialistiche}
2193 \label{sec:process_special}
2197 \subsection{La gestione delle operazioni in virgola mobile}
2198 \label{sec:process_fenv}
2202 % TODO eccezioni ed arrotondamenti per la matematica in virgola mobile
2203 % consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater,
2204 % isnan, nan, INFINITY
2207 \subsection{L'accesso alle porte di I/O}
2208 \label{sec:process_io_port}
2211 % TODO l'I/O sulle porte di I/O
2212 % consultare le manpage di ioperm, iopl e outb
2213 % non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
2219 %\subsection{La gestione di architetture a nodi multipli}
2220 %\label{sec:process_NUMA}
2222 % TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati
2223 % per associare l'uso di gruppi di processori a gruppi di processi (vedi
2225 % TODO trattare getcpu, che attiene anche a NUMA, mettere qui anche
2226 % sched_getcpu, che potrebbe essere indipendente ma richiama getcpu
2228 %TODO trattare le funzionalità per il NUMA
2229 % vedi man numa e, mbind, get_mempolicy, set_mempolicy,
2230 % le pagine di manuale relative
2231 % vedere anche dove metterle...
2233 % \subsection{La gestione dei moduli}
2234 % \label{sec:kernel_modules}
2238 %TODO trattare init_module e finit_module (quest'ultima introdotta con il
2241 %%%% Altre cose di cui non è chiara la collocazione:
2243 %TODO trattare membarrier, introdotta con il kernel 4.3
2244 % vedi http://lwn.net/Articles/369567/ http://lwn.net/Articles/369640/
2245 % http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b25b13ab08f616efd566347d809b4ece54570d1
2246 % vedi anche l'ulteriore opzione "expedited" introdotta con il kernel 4.14
2247 % (https://lwn.net/Articles/728795/)
2251 %%% Local Variables:
2253 %%% TeX-master: "gapil"
2256 % LocalWords: system call namespace prctl IRIX kernel sys int option long
2257 % LocalWords: unsigned arg errno EACCESS EBADF EBUSY EFAULT EINVAL ENXIO PR
2258 % LocalWords: EOPNOTSUPP EPERM CAPBSET READ capability sez tab capabilities
2259 % LocalWords: bounding CAP SETPCAP DUMPABLE dump suid sgid UID DISABLE GET
2260 % LocalWords: ENDIAN endianness BIG big endian LITTLE little PPC PowerPC ia
2261 % LocalWords: FPEMU NOPRINT SIGFPE FPEXC point exception FP EXC SW ENABLE
2262 % LocalWords: OVF overflow UND underflow RES INV DISABLED NONRECOV ASYNC AO
2263 % LocalWords: KEEPCAPS pag exec SECURE KEEP CAPS securebits LOCKED NAME NUL
2264 % LocalWords: char PDEATHSIG SIGCHLD fork PTRACER PID tracer process ptrace
2265 % LocalWords: Security Modules ANY Yama SECCOMP secure computing seccomp vm
2266 % LocalWords: STRICT strict FILTER filter SIGKILL TIMING STATISTICAL TSC fn
2267 % LocalWords: TIMESTAMP timestamp Stamp Counter SIGSEGV UNALIGN SIGBUS MCE
2268 % LocalWords: KILL siginfo MCEERR memory failure early kill CLEAR child cap
2269 % LocalWords: reaper SUBREAPER init value result thread like flags stack FS
2270 % LocalWords: race condition malloc NULL copy write glibc vsyscall sched RT
2271 % LocalWords: void pid ptid struct desc tls ctid EAGAIN ENOMEM exit Posix
2272 % LocalWords: Library PARENT SETTID SETTLS TID CLEARTID futex FILES table
2273 % LocalWords: descriptor umask dell'I scheduler SIGHAND STOPPED SYSVSEM IPC
2274 % LocalWords: UNTRACED VFORK vfork mount filesystem LSM Mandatory Access fs
2275 % LocalWords: Control DAC MAC SELinux Smack Tomoyo AppArmor Discrectionary
2276 % LocalWords: permitted inheritable effective fig security ADMIN forced new
2277 % LocalWords: allowed dall' bound MODULE nell' all' capset sendmail SETGID
2278 % LocalWords: setuid orig IMMUTABLE MKNOD OVERRIDE SEARCH CHOWN FSETID LOCK
2279 % LocalWords: FOWNER saved FIXUP NOROOT AUDIT BLOCK SUSPEND SETFCAP group
2280 % LocalWords: socket domain locking mlock mlockall shmctl mmap OWNER LEASE
2281 % LocalWords: lease immutable append only mknod BIND SERVICE BROADCAST RAW
2282 % LocalWords: broadcast multicast PACKET CHROOT chroot NICE PACCT RAWIO TTY
2283 % LocalWords: accounting ioperm iopl RESOURCE CONFIG hangup vhangup SYSLOG
2284 % LocalWords: WAKE ALARM CLOCK BOOTTIME REALTIME sticky NOATIME fcntl swap
2285 % LocalWords: multicasting dell'IPC SysV trusted IOPRIO CLASS IDLE lookup
2286 % LocalWords: scheduling dcookie NEWNS unshare nice NUMA ioctl journaling
2287 % LocalWords: ext capget header hdrp datap const ESRCH SOURCE undef version
2288 % LocalWords: libcap lcap obj to text dup clear DIFFERS get ncap caps ssize
2289 % LocalWords: argument length all setpcap from string name proc cat capgetp
2290 % LocalWords: capsetp getcap read sigreturn sysctl protected hardlinks tmp
2291 % LocalWords: dell' symlink symlinks pathname TOCTTOU of
projects / gapil.git / blob