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