1 \chapter{La gestione avanzata dei processi}
2 \label{cha:proc_advanced}
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.
12 \section{La gestione avanzata della sicurezza}
13 \label{sec:process_security}
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
24 \subsection{La gestione delle \textit{capabilities}}
25 \label{sec:proc_capabilities}
27 \itindbeg{capabilities}
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à).
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.
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
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}''.
70 \itindbeg{file~capabilities}
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}.
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}.
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.
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
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}
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
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).
166 \itindbeg{capabilities~bounding~set}
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.
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}.}
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
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}).
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.
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.
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}.}
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.
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:
261 \includecodesnip{listati/cap-results.c}
263 % \begin{figure}[!htbp]
264 % \footnotesize \centering
265 % \begin{minipage}[c]{12cm}
266 % \includecodesnip{listati/cap-results.c}
268 % \caption{Espressione della modifica delle \textit{capabilities} attraverso
270 % \label{fig:cap_across_exec}
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}.
278 \itindend{capabilities~bounding~set}
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.
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.
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
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}.
328 \label{sec:capability-uid-transition}
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}.
339 \itindbeg{securebits}
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}.
353 \begin{tabular}{|l|p{10cm}|}
355 \textbf{Flag} & \textbf{Descrizione} \\
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
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}).\\
382 \caption{Costanti identificative dei flag che compongono la maschera dei
383 \textit{securebits}.}
384 \label{tab:securebits_values}
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}.
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}.
407 \itindend{securebits}
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}.
419 \itindend{file~capabilities}
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
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/
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.
446 \begin{tabular}{|l|p{10cm}|}
448 \textbf{Capacità}&\textbf{Descrizione}\\
452 % POSIX-draft defined capabilities.
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 sez.~\ref{sec:file_access_control}).\\
467 \constd{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
468 permessi di lettura ed esecuzione per
470 sez.~\ref{sec:file_access_control}).\\
471 \const{CAP\_FOWNER} & Evitare il controllo della proprietà di un file
472 per tutte le operazioni privilegiate non coperte
473 dalle precedenti \const{CAP\_DAC\_OVERRIDE} e
474 \const{CAP\_DAC\_READ\_SEARCH}.\\
475 \constd{CAP\_FSETID} & Evitare la cancellazione automatica dei bit
476 \acr{suid} e \acr{sgid} quando un file
477 per i quali sono impostati viene modificato da
478 un processo senza questa capacità e la capacità
479 di impostare il bit \acr{sgid} su un file anche
480 quando questo è relativo ad un gruppo cui non si
482 sez.~\ref{sec:file_perm_management}).\\
483 \constd{CAP\_KILL} & Mandare segnali a qualunque
484 processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
485 \constd{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file
486 (dal kernel 2.6.24).\\
487 \constd{CAP\_SETGID} & Manipolare i group ID dei
488 processi, sia il principale che i supplementari,
489 (vedi sez.~\ref{sec:proc_setgroups}) che quelli
490 trasmessi tramite i socket \textit{unix domain}
491 (vedi sez.~\ref{sec:unix_socket}).\\
492 \constd{CAP\_SETUID} & Manipolare gli user ID del
493 processo (vedi sez.~\ref{sec:proc_setuid}) e di
494 trasmettere un user ID arbitrario nel passaggio
495 delle credenziali coi socket \textit{unix
496 domain} (vedi sez.~\ref{sec:unix_socket}).\\
498 % Linux specific capabilities
501 \constd{CAP\_IPC\_LOCK} & Effettuare il \textit{memory locking} con le
502 funzioni \func{mlock}, \func{mlockall},
503 \func{shmctl}, \func{mmap} (vedi
504 sez.~\ref{sec:proc_mem_lock} e
505 sez.~\ref{sec:file_memory_map}). \\
506 % TODO verificare l'interazione con SHM_HUGETLB
507 \constd{CAP\_IPC\_OWNER}& Evitare il controllo dei permessi
508 per le operazioni sugli oggetti di
509 intercomunicazione fra processi (vedi
510 sez.~\ref{sec:ipc_sysv}).\\
511 \constd{CAP\_LEASE} & Creare dei \textit{file lease} (vedi
512 sez.~\ref{sec:file_asyncronous_lease})
513 pur non essendo proprietari del file (dal kernel
515 \constd{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
516 \textit{immutable} e \textit{append-only} (vedi
517 sez.~\ref{sec:file_perm_overview}) se
519 \constd{CAP\_MAC\_ADMIN}& Amministrare il \textit{Mandatory
520 Access Control} di \textit{Smack} (dal kernel
522 \constd{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
523 Access Control} di \textit{Smack} (dal kernel
525 \constd{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
526 sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
527 \const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
528 privilegiate sulla rete.\\
529 \constd{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
530 sez.~\ref{sec:TCP_func_bind}).\\
531 \constd{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
532 \textit{broadcast} e \textit{multicast}.\\
533 \constd{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
534 (vedi sez.~\ref{sec:sock_type}).\\
535 \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
536 \textit{capabilities}.\\
537 \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti amministrativi.\\
538 \constd{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
539 sez.~\ref{sec:sys_reboot}).\\
540 \constd{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
541 sez.~\ref{sec:file_chroot}).\\
542 \constd{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
543 \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi
544 sez.~\ref{sec:proc_priority}).\\
545 \constd{CAP\_SYS\_PACCT}& Usare le funzioni di \textit{accounting} dei
547 sez.~\ref{sec:sys_bsd_accounting}).\\
548 \constd{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
550 sez.~\ref{sec:process_ptrace}).\\
551 \constd{CAP\_SYS\_RAWIO}& Operare sulle porte di I/O con \func{ioperm} e
553 sez.~\ref{sec:process_io_port}).\\
554 \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni sulle risorse.\\
555 \constd{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
556 sez.~\ref{sec:sys_time}).\\
557 \constd{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
558 con la funzione \func{vhangup}.\\
559 \constd{CAP\_SYSLOG} & Gestire il buffer dei messaggi
560 del kernel, (vedi sez.~\ref{sec:sess_daemon}),
561 introdotta dal kernel 2.6.38 come capacità
562 separata da \const{CAP\_SYS\_ADMIN}.\\
563 \constd{CAP\_WAKE\_ALARM}&Usare i timer di tipo
564 \const{CLOCK\_BOOTTIME\_ALARM} e
565 \const{CLOCK\_REALTIME\_ALARM}, vedi
566 sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
569 \caption{Le costanti che identificano le \textit{capabilities} presenti nel
571 \label{tab:proc_capabilities}
574 \constbeg{CAP\_SETPCAP}
576 Prima di dettagliare il significato della capacità più generiche, conviene
577 però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
578 stato completamente cambiato con l'introduzione delle \textit{file
579 capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
580 che permetteva al processo che la possedeva di impostare o rimuovere le
581 \textit{capabilities} presenti nel suo \textit{permitted set} su un qualunque
582 altro processo. In realtà questo non è mai stato l'uso inteso nelle bozze
583 dallo standard POSIX, ed inoltre, come si è già accennato, dato che questa
584 capacità è sempre stata assente (a meno di specifiche ricompilazioni del
585 kernel) nel \textit{capabilities bounding set} usato di default, essa non è
586 neanche mai stata realmente disponibile.
588 Con l'introduzione \textit{file capabilities} e il cambiamento del significato
589 del \textit{capabilities bounding set} la possibilità di modificare le
590 capacità di altri processi è stata completamente rimossa, e
591 \const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
592 significato originario, e cioè la capacità del processo di poter inserire nel
593 suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
594 set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
595 processo di eliminare una capacità dal proprio \textit{bounding set} (con la
596 conseguente impossibilità successiva di eseguire programmi con quella
597 capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
599 \constend{CAP\_SETPCAP}
600 \constbeg{CAP\_FOWNER}
602 La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
603 maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
604 processo che non ha la proprietà di un file in un vasto campo di
605 operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del
606 processo (o meglio l'\ids{UID} di filesystem, vedi
607 sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste
608 comprendono i cambiamenti dei permessi e dei tempi del file (vedi
609 sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
610 impostazioni degli attributi dei file e delle ACL (vedi
611 sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
612 \textit{sticky bit} nella cancellazione dei file (vedi
613 sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
614 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
615 sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl_ioctl}) senza
618 \constend{CAP\_FOWNER}
619 \constbeg{CAP\_NET\_ADMIN}
621 Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
622 la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
623 privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
624 il \textit{multicasting} (vedi sez.\ref{sec:sock_ipv4_options}), eseguire la
625 configurazione delle interfacce di rete (vedi
626 sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la tabella di instradamento.
628 \constend{CAP\_NET\_ADMIN}
629 \constbeg{CAP\_SYS\_ADMIN}
631 Una terza \textit{capability} con vasto campo di applicazione è
632 \const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
633 come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
634 disattivare la \textit{swap}, montare, rimontare e smontare filesystem (vedi
635 sez.~\ref{sec:filesystem_mounting}), effettuare operazioni di controllo su
636 qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
637 sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
638 (vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella
639 trasmissione delle credenziali dei socket (vedi
640 sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
641 (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
642 \const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
643 sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
644 di file aperti,\footnote{quello indicato da \sysctlfiled{fs/file-max}.}
645 effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
646 sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
647 usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
648 sez.~\ref{sec:process_clone}).
650 \constend{CAP\_SYS\_ADMIN}
651 \constbeg{CAP\_SYS\_NICE}
653 Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
654 aumentare le priorità di esecuzione dei processi, come la diminuzione del
655 valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
656 priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
657 l'impostazione delle affinità di processore (vedi
658 sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
659 anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
660 alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
661 arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
662 politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
664 \constend{CAP\_SYS\_NICE}
665 \constbeg{CAP\_SYS\_RESOURCE}
667 Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
668 possibilità di superare i limiti imposti sulle risorse di sistema, come usare
669 lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
670 usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
671 filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
672 risorse di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul
673 numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
674 SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
676 \constend{CAP\_SYS\_RESOURCE}
678 Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
679 funzioni che permettono rispettivamente di leggere ed impostare i valori dei
680 tre insiemi illustrati in precedenza. Queste due funzioni di sistema sono
681 \funcd{capget} e \funcd{capset} e costituiscono l'interfaccia di gestione
682 basso livello; i loro rispettivi prototipi sono:
685 \fhead{sys/capability.h}
686 \fdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
687 \fdesc{Legge le \textit{capabilities}.}
688 \fdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t datap)}
689 \fdesc{Imposta le \textit{capabilities}.}
692 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
693 caso \var{errno} assumerà uno dei valori:
695 \item[\errcode{EFAULT}] si è indicato un puntatore sbagliato o nullo
696 per \param{hdrp} o \param{datap} (quest'ultimo può essere nullo solo se si
697 usa \func{capget} per ottenere la versione delle \textit{capabilities}
699 \item[\errcode{EINVAL}] si è specificato un valore non valido per uno dei
700 campi di \param{hdrp}, in particolare una versione non valida della
701 versione delle \textit{capabilities}.
702 \item[\errcode{EPERM}] si è tentato di aggiungere una capacità nell'insieme
703 delle \textit{capabilities} permesse, o di impostare una capacità non
704 presente nell'insieme di quelle permesse negli insieme delle effettive o
705 ereditate, o si è cercato di impostare una \textit{capability} di un altro
706 processo senza avare \const{CAP\_SETPCAP}.
707 \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
712 Queste due funzioni prendono come argomenti due tipi di dati dedicati,
713 definiti come puntatori a due strutture specifiche di Linux, illustrate in
714 fig.~\ref{fig:cap_kernel_struct}. Per un certo periodo di tempo era anche
715 indicato che per poterle utilizzare fosse necessario che la macro
716 \macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
717 una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
718 \headfiled{sys/capability.h}) requisito che non risulta più
719 presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
725 \begin{minipage}[c]{0.8\textwidth}
726 \includestruct{listati/cap_user_header_t.h}
729 \caption{Definizione delle strutture a cui fanno riferimento i puntatori
730 \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
731 l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
732 \label{fig:cap_kernel_struct}
735 Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
736 prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
737 essere modificate con il cambiamento del kernel (in particolare i tipi di dati
738 delle strutture) ed anche se finora l'interfaccia è risultata stabile, non c'è
739 nessuna assicurazione che questa venga mantenuta,\footnote{viene però
740 garantito che le vecchie funzioni continuino a funzionare.} Pertanto se si
741 vogliono scrivere programmi portabili che possano essere eseguiti senza
742 modifiche o adeguamenti su qualunque versione del kernel è opportuno
743 utilizzare le interfacce di alto livello che vedremo più avanti.
745 La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
746 tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono
747 leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
748 usano le \textit{file capabilities}, può essere solo 0 o il \ids{PID} del
749 processo chiamante, che sono equivalenti. Non tratteremo, essendo comunque di
750 uso irrilevante, il caso in cui, in mancanza di tale supporto, la funzione può
751 essere usata per modificare le \textit{capabilities} di altri processi, per il
752 quale si rimanda, se interessati, alla lettura della pagina di manuale.
754 Il campo \var{version} deve essere impostato al valore della versione delle
755 stesse usata dal kernel (quello indicato da una delle costanti
756 \texttt{\_LINUX\_CAPABILITY\_VERSION\_n} di fig.~\ref{fig:cap_kernel_struct})
757 altrimenti le funzioni ritorneranno con un errore di \errcode{EINVAL},
758 restituendo nel campo stesso il valore corretto della versione in uso. La
759 versione due è comunque deprecata e non deve essere usata, ed il kernel
760 stamperà un avviso se lo si fa.
762 I valori delle \textit{capabilities} devono essere passati come maschere
763 binarie;\footnote{e si tenga presente che i valori di
764 tab.~\ref{tab:proc_capabilities} non possono essere combinati direttamente,
765 indicando il numero progressivo del bit associato alla relativa capacità.}
766 con l'introduzione delle \textit{capabilities} a 64 bit inoltre il
767 puntatore \param{datap} non può essere più considerato come relativo ad una
768 singola struttura, ma ad un vettore di due strutture.\footnote{è questo cambio
769 di significato che ha portato a deprecare la versione 2, che con
770 \func{capget} poteva portare ad un buffer overflow per vecchie applicazioni
771 che continuavano a considerare \param{datap} come puntatore ad una singola
774 Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
775 garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
776 gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
777 questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
778 dello standard POSIX.1e, non fanno parte della \acr{glibc} e sono fornite in
779 una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
780 Debian può essere installata con il pacchetto omonimo.} pertanto se un
781 programma le utilizza si dovrà indicare esplicitamente al compilatore l'uso
782 della suddetta libreria attraverso l'opzione \texttt{-lcap}.
784 \itindbeg{capability~state}
786 Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
787 dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
788 \typed{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
789 \textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
790 una struttura interna utilizzata dalle librerie, i cui campi non devono mai
791 essere acceduti direttamente.} in sono memorizzati tutti i dati delle
792 \textit{capabilities}.
794 In questo modo è possibile mascherare i dettagli della gestione di basso
795 livello, che potranno essere modificati senza dover cambiare le funzioni
796 dell'interfaccia, che fanno riferimento soltanto ad oggetti di questo tipo.
797 L'interfaccia pertanto non soltanto fornisce le funzioni per modificare e
798 leggere le \textit{capabilities}, ma anche quelle per gestire i dati
799 attraverso i \textit{capability state}, che presentano notevoli affinità,
800 essendo parte di bozze dello stesso standard, con quelle già viste per le ACL.
802 La prima funzione dell'interfaccia è quella che permette di inizializzare un
803 \textit{capability state}, allocando al contempo la memoria necessaria per i
804 relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
807 \fhead{sys/capability.h}
808 \fdecl{cap\_t cap\_init(void)}
809 \fdesc{Crea ed inizializza un \textit{capability state}.}
812 {La funzione ritorna un \textit{capability state} in caso di successo e
813 \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
814 valore \errval{ENOMEM}. }
817 La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
818 con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
819 non c'è memoria sufficiente ad allocare i dati) viene restituito \val{NULL}
820 ed \var{errno} viene impostata a \errval{ENOMEM}.
822 La memoria necessaria a mantenere i dati viene automaticamente allocata da
823 \func{cap\_init}, ma dovrà essere disallocata esplicitamente quando non è più
824 necessaria utilizzando, per questo l'interfaccia fornisce una apposita
825 funzione, \funcd{cap\_free}, il cui prototipo è:
828 \fhead{sys/capability.h}
829 \fdecl{int cap\_free(void *obj\_d)}
830 \fdesc{Disalloca la memoria allocata per i dati delle \textit{capabilities}..}
833 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
834 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
839 La funzione permette di liberare la memoria allocata dalle altre funzioni
840 della libreria sia per un \textit{capability state}, nel qual caso l'argomento
841 sarà un dato di tipo \type{cap\_t}, che per una descrizione testuale dello
842 stesso,\footnote{cioè quanto ottenuto tramite la funzione
843 \func{cap\_to\_text}.} nel qual caso l'argomento sarà un dato di tipo
844 \texttt{char *}. Per questo motivo l'argomento \param{obj\_d} è dichiarato
845 come \texttt{void *}, per evitare la necessità di eseguire un \textit{cast},
846 ma dovrà comunque corrispondere ad un puntatore ottenuto tramite le altre
847 funzioni della libreria, altrimenti la funzione fallirà con un errore di
850 Infine si può creare una copia di un \textit{capability state} ottenuto in
851 precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
854 \fhead{sys/capability.h}
855 \fdecl{cap\_t cap\_dup(cap\_t cap\_p)}
856 \fdesc{Duplica un \textit{capability state} restituendone una copia.}
859 {La funzione ritorna un \textit{capability state} in caso di successo e
860 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
861 \errval{ENOMEM} o \errval{EINVAL} nel loro significato generico.}
865 La funzione crea una copia del \textit{capability state} posto all'indirizzo
866 \param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
867 copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
868 nell'originale. La memoria necessaria viene allocata automaticamente dalla
869 funzione. Una volta effettuata la copia i due \textit{capability state}
870 potranno essere modificati in maniera completamente indipendente, ed alla fine
871 delle operazioni si dovrà disallocare anche la copia, oltre all'originale.
873 Una seconda classe di funzioni di servizio previste dall'interfaccia sono
874 quelle per la gestione dei dati contenuti all'interno di un \textit{capability
875 state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
878 \fhead{sys/capability.h}
879 \fdecl{int cap\_clear(cap\_t cap\_p)}
880 \fdesc{Inizializza un \textit{capability state} cancellando tutte le
881 \textit{capabilities}.}
884 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
885 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
889 La funzione si limita ad azzerare tutte le \textit{capabilities} presenti nel
890 \textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
891 restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
892 creazione con \func{cap\_init}.
894 Una variante di \func{cap\_clear} è \funcd{cap\_clear\_flag} che cancella da
895 un \textit{capability state} tutte le \textit{capabilities} di un certo
896 insieme fra quelli elencati a pag.~\pageref{sec:capabilities_set}, il suo
900 \fhead{sys/capability.h}
901 \fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
902 \fdesc{Cancella delle \textit{capabilities} da un \textit{capability state}.}
905 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
906 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
910 La funzione richiede che si indichi quale degli insiemi si intente cancellare
911 da \param{cap\_p} con l'argomento \param{flag}. Questo deve essere specificato
912 con una variabile di tipo \type{cap\_flag\_t} che può assumere
913 esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
914 verificare dalla sua definizione che si trova in
915 \headfile{sys/capability.h}.} uno dei valori illustrati in
916 tab.~\ref{tab:cap_set_identifier}.
921 \begin{tabular}[c]{|l|l|}
923 \textbf{Valore} & \textbf{Significato} \\
926 \constd{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
927 \constd{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
928 \constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
931 \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
932 identifica gli insiemi delle \textit{capabilities}.}
933 \label{tab:cap_set_identifier}
936 Si possono inoltre confrontare in maniera diretta due diversi
937 \textit{capability state} con la funzione \funcd{cap\_compare}; il suo
941 \fhead{sys/capability.h}
942 \fdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
943 \fdesc{Confronta due \textit{capability state}.}
946 {La funzione ritorna $0$ se i \textit{capability state} sono identici
947 ed un valore positivo se differiscono, non sono previsti errori.}
951 La funzione esegue un confronto fra i due \textit{capability state} passati
952 come argomenti e ritorna in un valore intero il risultato, questo è nullo se
953 sono identici o positivo se vi sono delle differenze. Il valore di ritorno
954 della funzione consente inoltre di per ottenere ulteriori informazioni su
955 quali sono gli insiemi di \textit{capabilities} che risultano differenti. Per
956 questo si può infatti usare la apposita macro \macro{CAP\_DIFFERS}:
961 \fhead{sys/capability.h}
962 \fdecl{int \macrod{CAP\_DIFFERS}(value, flag)}
963 \fdesc{Controlla lo stato di eventuali differenze delle \textit{capabilities}
964 nell'insieme \texttt{flag}.}
969 La macro richiede che si passi nell'argomento \texttt{value} il risultato
970 della funzione \func{cap\_compare} e in \texttt{flag} l'indicazione (coi
971 valori di tab.~\ref{tab:cap_set_identifier}) dell'insieme che si intende
972 controllare; restituirà un valore diverso da zero se le differenze rilevate da
973 \func{cap\_compare} sono presenti nell'insieme indicato.
975 Per la gestione dei singoli valori delle \textit{capabilities} presenti in un
976 \textit{capability state} l'interfaccia prevede due funzioni specifiche,
977 \funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
978 rispettivamente di leggere o impostare il valore di una capacità all'interno
979 in uno dei tre insiemi già citati; i rispettivi prototipi sono:
982 \fhead{sys/capability.h}
983 \fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
985 \phantom{int cap\_get\_flag(}cap\_flag\_value\_t *value\_p)}
986 \fdesc{Legge il valore di una \textit{capability}.}
987 \fdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
988 cap\_value\_t *caps, \\
989 \phantom{int cap\_set\_flag(}cap\_flag\_value\_t value)}
990 \fdesc{Imposta il valore di una \textit{capability}.}
993 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
994 caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
998 In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
999 \textit{capability state} su cui operare, mentre l'argomento \param{flag}
1000 indica su quale dei tre insiemi si intende operare, sempre con i valori di
1001 tab.~\ref{tab:cap_set_identifier}. La capacità che si intende controllare o
1002 impostare invece deve essere specificata attraverso una variabile di tipo
1003 \typed{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
1004 riportati in tab.~\ref{tab:proc_capabilities}, in questo caso però non è
1005 possibile combinare diversi valori in una maschera binaria, una variabile di
1006 tipo \type{cap\_value\_t} può indicare una sola capacità.\footnote{in
1007 \headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
1008 \ctyp{int}, ma i valori validi sono soltanto quelli di
1009 tab.~\ref{tab:proc_capabilities}.}
1011 Infine lo stato di una capacità è descritto ad una variabile di tipo
1012 \type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
1013 uno\footnote{anche questo è un tipo enumerato.} dei valori di
1014 tab.~\ref{tab:cap_value_type}.
1019 \begin{tabular}[c]{|l|l|}
1021 \textbf{Valore} & \textbf{Significato} \\
1024 \constd{CAP\_CLEAR}& La capacità non è impostata.\\
1025 \constd{CAP\_SET} & La capacità è impostata.\\
1028 \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
1029 indica lo stato di una capacità.}
1030 \label{tab:cap_value_type}
1033 La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
1034 dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
1035 \param{flag} e lo restituisce come \textit{value result argument} nella
1036 variabile puntata dall'argomento \param{value\_p}. Questa deve essere di tipo
1037 \type{cap\_flag\_value\_t} ed assumerà uno dei valori di
1038 tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
1039 lo stato di una capacità alla volta.
1041 La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
1042 più \textit{capabilities}, anche se solo all'interno dello stesso insieme ed
1043 allo stesso valore. Per questo motivo essa prende un vettore di valori di tipo
1044 \type{cap\_value\_t} nell'argomento \param{caps}, la cui dimensione viene
1045 specificata dall'argomento \param{ncap}. Il tipo di impostazione da eseguire
1046 (cancellazione o attivazione) per le capacità elencate in \param{caps} viene
1047 indicato dall'argomento \param{value} sempre con i valori di
1048 tab.~\ref{tab:cap_value_type}.
1050 Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede
1051 che sia possibile utilizzare anche una rappresentazione testuale del contenuto
1052 di un \textit{capability state} e fornisce le opportune funzioni di
1053 gestione;\footnote{entrambe erano previste dalla bozza dello standard
1054 POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione
1055 testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
1058 \fhead{sys/capability.h}
1059 \fdecl{char *cap\_to\_text(cap\_t caps, ssize\_t *length\_p)}
1060 \fdesc{Genera una visualizzazione testuale delle \textit{capabilities}.}
1063 {La funzione ritorna un puntatore alla stringa con la descrizione delle
1064 \textit{capabilities} in caso di successo e \val{NULL} per un errore, nel
1065 qual caso \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM}
1066 nel loro significato generico.}
1069 La funzione ritorna l'indirizzo di una stringa contente la descrizione
1070 testuale del contenuto del \textit{capability state} \param{caps} passato come
1071 argomento, e, qualora l'argomento \param{length\_p} sia diverso da \val{NULL},
1072 restituisce come \textit{value result argument} nella variabile intera da
1073 questo puntata la lunghezza della stringa. La stringa restituita viene
1074 allocata automaticamente dalla funzione e pertanto dovrà essere liberata con
1077 La rappresentazione testuale, che viene usata anche dai programmi di gestione a
1078 riga di comando, prevede che lo stato venga rappresentato con una stringa di
1079 testo composta da una serie di proposizioni separate da spazi, ciascuna delle
1080 quali specifica una operazione da eseguire per creare lo stato finale. Nella
1081 rappresentazione si fa sempre conto di partire da uno stato in cui tutti gli
1082 insiemi sono vuoti e si provvede a impostarne i contenuti.
1084 Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i
1085 nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un
1086 operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I
1087 nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene
1088 inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a
1089 scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
1090 iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
1091 l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
1092 essere sempre minuscole, e se ne può indicare più di uno.
1094 Gli operatori possibili sono solo tre: ``\texttt{+}'' che aggiunge le capacità
1095 elencate agli insiemi indicati, ``\texttt{-}'' che le toglie e ``\texttt{=}''
1096 che le assegna esattamente. I primi due richiedono che sia sempre indicato sia
1097 un elenco di capacità che gli insiemi a cui esse devono applicarsi, e
1098 rispettivamente attiveranno o disattiveranno le capacità elencate nell'insieme
1099 o negli insiemi specificati, ignorando tutto il resto. I due operatori possono
1100 anche essere combinati nella stessa proposizione, per aggiungere e togliere le
1101 capacità dell'elenco da insiemi diversi.
1103 L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
1104 pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
1105 di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
1106 specificati, questo significa che in genere lo si usa una sola volta
1107 all'inizio della stringa. In tal caso l'elenco delle capacità può non essere
1108 indicato e viene assunto che si stia facendo riferimento a tutte quante senza
1109 doverlo scrivere esplicitamente.
1111 Come esempi avremo allora che un processo non privilegiato di un utente, che
1112 non ha nessuna capacità attiva, avrà una rappresentazione nella forma
1113 ``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a
1114 nessun insieme (vale la cancellazione preventiva), mentre un processo con
1115 privilegi di amministratore avrà una rappresentazione nella forma
1116 ``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi
1117 \textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato
1118 in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
1119 capacità verranno comunque attivate attraverso una \func{exec}). Infine, come
1120 esempio meno banale dei precedenti, otterremo per \texttt{init} una
1121 rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come
1122 accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
1125 Viceversa per ottenere un \textit{capability state} dalla sua rappresentazione
1126 testuale si può usare la funzione \funcd{cap\_from\_text}, il cui prototipo è:
1129 \fhead{sys/capability.h}
1130 \fdecl{cap\_t cap\_from\_text(const char *string)}
1131 \fdesc{Crea un \textit{capability state} dalla sua rappresentazione testuale.}
1134 {La funzione ritorna un \textit{capability state} in caso di successo e
1135 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1136 \errval{EINVAL} o \errval{ENOMEM} nel loro significato generico.}
1140 La funzione restituisce il puntatore ad un \textit{capability state}
1141 inizializzato con i valori indicati nella stringa \param{string} che ne
1142 contiene la rappresentazione testuale. La memoria per il \textit{capability
1143 state} viene allocata automaticamente dalla funzione e dovrà essere liberata
1144 con \func{cap\_free}.
1146 Alle due funzioni citate se ne aggiungono altre due che consentono di
1147 convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
1148 stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
1149 \funcd{cap\_to\_name} e \funcd{cap\_from\_name}, sono estensioni specifiche di
1150 Linux ed i rispettivi prototipi sono:
1153 \fhead{sys/capability.h}
1154 \fdecl{char *cap\_to\_name(cap\_value\_t cap)}
1155 \fdesc{Converte il valore numerico di una \textit{capabilities} alla sua
1156 rappresentazione testuale.}
1157 \fdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
1159 \fdesc{Converte la rappresentazione testuale di una \textit{capabilities} al
1160 suo valore numerico.}
1163 {La funzione \func{cap\_to\_name} ritorna un puntatore ad una stringa in caso
1164 di successo e \val{NULL} per un errore, mentre \func{cap\_to\_name} ritorna
1165 $0$ in caso di successo e $-1$ per un errore, per entrambe in caso di errore
1166 \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM} nel loro
1167 significato generico.
1171 La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
1172 essere liberata con \func{cap\_free}) che corrisponde al valore della
1173 capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
1174 da \param{cap\_p}, come \textit{value result argument}, il valore della
1175 capacità rappresentata dalla stringa \param{name}.
1177 Fin quei abbiamo trattato solo le funzioni di servizio relative alla
1178 manipolazione dei \textit{capability state} come strutture di dati;
1179 l'interfaccia di gestione prevede però anche le funzioni per trattare le
1180 \textit{capabilities} presenti nei processi. La prima di queste funzioni è
1181 \funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
1182 processo corrente, il suo prototipo è:
1185 \fhead{sys/capability.h}
1186 \fdecl{cap\_t cap\_get\_proc(void)}
1187 \fdesc{Legge le \textit{capabilities} del processo corrente.}
1190 {La funzione ritorna un \textit{capability state} in caso di successo e
1191 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1192 \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM} nel loro significato
1196 La funzione legge il valore delle \textit{capabilities} associate al processo
1197 da cui viene invocata, restituendo il risultato tramite il puntatore ad un
1198 \textit{capability state} contenente tutti i dati che provvede ad allocare
1199 autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
1200 non sarà più utilizzato.
1202 Se invece si vogliono leggere le \textit{capabilities} di un processo
1203 specifico occorre usare la funzione \funcd{cap\_get\_pid}, il cui
1204 prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
1205 prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
1206 ma il valore di ritorno è intero, come si può verificare anche dalla
1207 dichiarazione della stessa in \headfile{sys/capability.h}.} è:
1210 \fhead{sys/capability.h}
1211 \fdecl{cap\_t cap\_get\_pid(pid\_t pid)}
1212 \fdesc{Legge le \textit{capabilities} di un processo.}
1215 {La funzione ritorna un \textit{capability state} in caso di successo e
1216 \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
1217 \errval{ESRCH} o \errval{ENOMEM} nel loro significato generico. }
1220 La funzione legge il valore delle \textit{capabilities} del processo indicato
1221 con l'argomento \param{pid}, e restituisce il risultato tramite il puntatore
1222 ad un \textit{capability state} contenente tutti i dati che provvede ad
1223 allocare autonomamente e che al solito deve essere disallocato con
1224 \func{cap\_free}. Qualora il processo indicato non esista si avrà un errore di
1225 \errval{ESRCH}. Gli stessi valori possono essere letti direttamente nel
1226 filesystem \textit{proc}, nei file \texttt{/proc/<pid>/status}; ad esempio per
1227 \texttt{init} si otterrà qualcosa del tipo:
1229 piccardi@hain:~/gapil$ \textbf{cat /proc/1/status}
1231 CapInh: 0000000000000000
1232 CapPrm: 00000000fffffeff
1233 CapEff: 00000000fffffeff
1238 \itindend{capability~state}
1240 Infine per impostare le \textit{capabilities} del processo corrente (nella
1241 bozza dello standard POSIX.1e non esiste una funzione che permetta di cambiare
1242 le \textit{capabilities} di un altro processo) si deve usare la funzione
1243 \funcd{cap\_set\_proc}, il cui prototipo è:
1246 \fhead{sys/capability.h}
1247 \fdecl{int cap\_set\_proc(cap\_t cap\_p)}
1248 \fdesc{Imposta le \textit{capabilities} del processo corrente.}
1251 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1252 caso \var{errno} assumerà i valori:
1254 \item[\errcode{EPERM}] si è cercato di attivare una capacità non permessa.
1255 \end{errlist} ed inoltre \errval{EINVAL} nel suo significato generico.}
1258 La funzione modifica le \textit{capabilities} del processo corrente secondo
1259 quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
1260 possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
1261 impostare capacità non presenti nell'insieme di quelle permesse).
1263 In caso di successo i nuovi valori saranno effettivi al ritorno della
1264 funzione, in caso di fallimento invece lo stato delle capacità resterà
1265 invariato. Si tenga presente che \textsl{tutte} le capacità specificate
1266 tramite \param{cap\_p} devono essere permesse; se anche una sola non lo è la
1267 funzione fallirà, e per quanto appena detto, lo stato delle
1268 \textit{capabilities} non verrà modificato (neanche per le parti eventualmente
1271 Oltre a queste funzioni su Linux sono presenti due ulteriori funzioni,
1272 \funcm{capgetp} e \funcm{capsetp}, che svolgono un compito analogo. Queste
1273 funzioni risalgono alla implementazione iniziale delle \textit{capabilities}
1274 ed in particolare \funcm{capsetp} consentirebbe anche, come possibile in quel
1275 caso, di cambiare le capacità di un altro processo. Le due funzioni oggi sono
1276 deprecate e pertanto eviteremo di trattarle, per chi fosse interessato si
1277 rimanda alla lettura della loro pagina di manuale.
1279 Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
1280 si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
1281 \textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
1282 quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
1283 sono le \textit{capabilities} standard che ottiene un processo lanciato
1284 dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
1285 processo qualunque il cui \ids{PID} viene passato come parametro dell'opzione.
1287 \begin{figure}[!htbp]
1288 \footnotesize \centering
1289 \begin{minipage}[c]{\codesamplewidth}
1290 \includecodesample{listati/getcap.c}
1293 \caption{Corpo principale del programma \texttt{getcap.c}.}
1294 \label{fig:proc_getcap}
1297 La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
1298 e si basa su una condizione sulla variabile \var{pid} che se si è usato
1299 l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
1300 che si è tralasciata) al valore del \ids{PID} del processo di cui si vuole
1301 leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
1302 (\texttt{\small 1-6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
1303 per ottenere lo stato delle capacità del processo, nel secondo (\texttt{\small
1304 7-13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
1305 il valore delle capacità del processo indicato.
1307 Il passo successivo è utilizzare (\texttt{\small 15}) \func{cap\_to\_text} per
1308 tradurre in una stringa lo stato, e poi (\texttt{\small 16}) stamparlo; infine
1309 (\texttt{\small 18-19}) si libera la memoria allocata dalle precedenti
1310 funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
1313 \itindend{capabilities}
1315 % TODO vedi http://lwn.net/Articles/198557/ e
1316 % http://www.madore.org/~david/linux/newcaps/
1322 \subsection{La gestione del \textit{Secure Computing}.}
1323 \label{sec:procadv_seccomp}
1325 \itindbeg{secure~computing~mode}
1327 Il \textit{secure computing mode} è un meccanismo ideato per fornire un
1328 supporto per l'esecuzione di codice esterno non fidato e non verificabile a
1329 scopo di calcolo. L'idea era quella di disporre di una modalità di esecuzione
1330 dei programmi che permettesse di vendere la capacità di calcolo della propria
1331 macchina ad un qualche servizio di calcolo distribuito, senza comprometterne
1332 la sicurezza eseguendo codice non sotto il proprio controllo.
1334 La prima versione del meccanismo è stata introdotta con il kernel
1335 2.6.23,\footnote{e disponibile solo avendo abilitato il supporto nel kernel
1336 con l'opzione di configurazione \texttt{CONFIG\_SECCOMP}.} è molto semplice,
1337 il \textit{secure computing mode} viene attivato con \func{prctl} usando
1338 l'opzione \const{PR\_SET\_SECCOMP}, ed indicando \const{SECCOMP\_MODE\_STRICT}
1339 come valore per \param{arg2} (all'epoca unico valore possibile). Una volta
1340 abilitato in questa modalità (in seguito denominata \textit{strict mode}) il
1341 processo o il \textit{thread} chiamante potrà utilizzare soltanto un insieme
1342 estremamente limitato di \textit{system call}: \func{read}, \func{write},
1343 \func{\_exit} e \funcm{sigreturn}; l'esecuzione di qualsiasi altra
1344 \textit{system call} comporta l'emissione di un \signal{SIGKILL} e conseguente
1345 terminazione immediata del processo.
1347 Si tenga presente che in questo caso, con versioni recenti della \acr{glibc}
1348 (il comportamento è stato introdotto con la 2.3), diventa impossibile usare
1349 anche \func{\_exit} in \textit{strict mode}, in quanto questa funzione viene
1350 intercettata ed al suo posto viene chiamata \func{exit\_group} (vedi
1351 sez.~\ref{sec:pthread_management}) che non è consentita e comporta un
1354 Si tenga presente che, non essendo \func{execve} fra le funzioni permesse, per
1355 poter eseguire un programma terzo essendo in \textit{strict mode} questo dovrà
1356 essere fornito in una forma di codice interpretabile fornito attraverso un
1357 socket o una \textit{pipe}, creati prima di lanciare il processo che eseguirà
1358 il codice non fidato.
1361 % TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
1362 % terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
1363 % Documentation/prctl/seccomp_filter.txt
1364 % vedi anche http://lwn.net/Articles/600250/
1366 % TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
1367 % * Documentation/prctl/seccomp_filter.txt
1368 % * http://lwn.net/Articles/475043/
1370 % TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
1371 % vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
1374 \itindend{secure~computing~mode}
1376 \subsection{Altre funzionalità di sicurezza.}
1377 \label{sec:procadv_security_misc}
1379 Oltre alle funzionalità specifiche esaminate nelle sezioni precedenti, il
1380 kernel supporta una varietà di ulteriori impostazioni di sicurezza,
1381 accessibili nelle maniere più varie, che abbiamo raccolto in questa sezione.
1383 Una serie di modalità di sicurezza sono attivabili a richiesta attraverso
1384 alcune opzioni di controllo attivabili via \func{sysctl} o il filesystem
1385 \texttt{/proc}, un elenco delle stesse e dei loro effetti è il seguente:
1387 \begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
1388 \item[\sysctlrelfiled{fs}{protected\_hardlinks}] Un valore nullo, il default,
1389 mantiene il comportamento standard che non pone restrizioni alla creazione
1390 di \textit{hard link}. Se il valore viene posto ad 1 vengono invece attivate
1391 una serie di restrizioni protettive, denominate
1392 \itindex{protected~hardlinks} \textit{protected hardlinks}, che se non
1393 soddisfatte causano il fallimento di \func{link} con un errore di
1394 \errval{EPERM}. Perché questo non avvenga almeno una delle seguenti
1395 condizioni deve essere soddisfatta:
1397 \item il chiamante deve avere privilegi amministrativi (la
1398 \textit{capability} \const{CAP\_FOWNER}). In caso di utilizzo
1399 dell'\textit{user namespace} oltre a possedere \const{CAP\_FOWNER} è
1400 necessario che l'\ids{UID} del proprietario del file sia mappato nel
1402 \item il \textit{filesystem} \ids{UID} del chiamante (normalmente
1403 equivalente all'\ids{UID} effettivo) deve corrispondere a quello del
1404 proprietario del file a cui si vuole effettuare il collegamento.
1405 \item devono essere soddisfatte tutte le seguenti condizioni:
1407 \item il file è un file ordinario
1408 \item il file non ha il \acr{suid} bit attivo
1409 \item il file non ha lo \acr{sgid} bit attivo ed il permesso di esecuzione
1411 \item il chiamante ha i permessi di lettura e scrittura sul file
1415 In sostanza in questo caso un utente potrà creare un collegamento diretto ad
1416 un altro file solo se ne è il proprietario o se questo è un file ordinario
1417 senza permessi speciali ed a cui ha accesso in lettura e scrittura.
1419 Questa funzionalità fornisce una protezione generica che non inficia l'uso
1420 ordinario di \func{link}, ma rende impraticabili una serie di possibili
1421 abusi della stessa; oltre ad impedire l'uso di un \textit{hard link} come
1422 variante in un attacco di \textit{symlink race} (eludendo i
1423 \textit{protected symlinks} di cui al punto successivo), evita anche che si
1424 possa lasciare un riferimento ad un eventuale programma \acr{suid}
1425 vulnerabile, creando un collegamento diretto allo stesso.
1428 \item[\sysctlrelfiled{fs}{protected\_symlinks}] Un valore nullo, il default,
1429 mantiene il comportamento standard che non pone restrizioni nel seguire i
1430 link simbolici. Se il valore viene posto ad 1 vengono attivate delle
1431 restrizioni protettive, denominate \itindex{protected~symlinks}
1432 \textit{protected symlinks}. Quando vengono attivate una qualunque funzione
1433 che esegua la risoluzione di un \textit{pathname} contenente un link
1434 simbolico non conforme alle restrizioni fallirà con un errore di
1435 \errval{EACCESS}. Per evitare l'errore deve essere soddisfatta una delle
1436 seguenti condizioni:
1438 \item il link non è in una directory con permessi analoghi a \file{/tmp}
1439 (scrivibile a tutti e con lo \textit{sticky bit} attivo);
1440 \item il link è in una directory con permessi analoghi a \file{/tmp} ma è
1441 soddisfatta una delle condizioni seguenti:
1443 \item il link simbolico appartiene al chiamante: il controllo viene fatto
1444 usando il \textit{filesystem} \ids{UID} (che normalmente corrisponde
1445 all'\ids{UID} effettivo).
1446 \item il link simbolico ha lo stesso proprietario della directory.
1450 Questa funzionalità consente di rendere impraticabili alcuni attacchi in cui
1451 si approfitta di una differenza di tempo fra il controllo e l'uso di un
1452 file, ed in particolare quella classe di attacchi viene usualmente chiamati
1453 \textit{symlink attack},\footnote{si tratta di un sottoinsieme di quella
1454 classe di attacchi chiamata genericamente \textit{TOCTTOU}, acronimo
1455 appunto di \textit{Time of check to time of use}.} di cui abbiamo parlato
1456 in sez.~\ref{sec:file_temp_file}.
1458 Un possibile esempio di questo tipo di attacco è quello contro un programma
1459 che viene eseguito per conto di un utente privilegiato (ad esempio un
1460 programma con il \acr{suid} o lo \acr{sgid} bit attivi) che prima controlla
1461 l'esistenza di un file e se non esiste lo crea. Se questa procedura, che è
1462 tipica della creazione di file temporanei sotto \file{/tmp}, non viene
1463 eseguita in maniera corretta,\footnote{ad esempio con le modalità che
1464 abbiamo trattato in sez.~\ref{sec:file_temp_file}, che per quanto note da
1465 tempo continuano ad essere ignorate.} un attaccante ha una finestra di
1466 tempo in cui può creare prima del programma un \textit{link simbolico} ad un
1467 file di sua scelta, compresi file di dispositivo o file a cui non avrebbe
1468 accesso, facendolo poi utilizzare al programma.
1470 Attivando la funzionalità si rende impossibile seguire un link simbolico in
1471 una directory temporanea come \texttt{/tmp}, a meno che questo non sia di
1472 proprietà del chiamante, o che questo non appartenga al proprietario della
1473 directory. Questo impedisce che i link simbolici creati da un attaccante
1474 possano essere seguiti da un programma privilegiato (perché apparterranno
1475 all'attaccante) mentre quelli creati dall'amministratore (che i genere è il
1476 proprietario di \texttt{/tmp}) saranno seguiti comunque.
1481 % TODO: trattare pure protected_regular e protected_fifos introdotti con il
1482 % 4.19 (vedi https://lwn.net/Articles/763106/)
1486 % TODO: trattare keyctl (man 2 keyctl)
1490 % TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
1491 % pkey_mprotect, introdotte con il kernel 4.8, vedi
1492 % http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
1494 \section{Funzioni di gestione e controllo}
1495 \label{sec:proc_manage_control}
1497 In questa sezione prenderemo in esame alcune specifiche \textit{system call}
1498 dedicate al controllo dei processi sia per quanto riguarda l'impostazione di
1499 caratteristiche specialistiche, che per quanto riguarda l'analisi ed il
1500 controllo della loro esecuzione.
1502 \subsection{La funzione \func{prctl}}
1503 \label{sec:process_prctl}
1505 Benché la gestione ordinaria dei processi possa essere effettuata attraverso
1506 le funzioni che abbiamo già esaminato nei capitoli \ref{cha:process_interface}
1507 e \ref{cha:process_handling}, esistono una serie di proprietà e
1508 caratteristiche specifiche dei processi per la cui gestione è stata
1509 predisposta una apposita \textit{system call} che fornisce una interfaccia
1510 generica per tutte le operazioni specialistiche. La funzione di sistema è
1511 \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è standardizzata
1512 ed è specifica di Linux, anche se ne esiste una analoga in IRIX; è stata
1513 introdotta con il kernel 2.1.57.}
1517 \fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned
1519 \phantom{int prctl(}unsigned long arg5)}
1520 \fdesc{Esegue una operazione speciale sul processo corrente.}
1523 {La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in
1524 caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
1525 valori diversi a seconda del tipo di operazione richiesta, sono possibili:
1526 \errval{EACCESS}, \errval{EBADF}, \errval{EBUSY}, \errval{EFAULT},
1527 \errval{EINVAL}, \errval{ENXIO}, \errval{EOPNOTSUPP} o \errval{EPERM}.}
1530 La funzione ritorna in caso di successo un valore nullo o positivo, e $-1$ in
1531 caso di errore. Il significato degli argomenti della funzione successivi al
1532 primo, il valore di ritorno in caso di successo, il tipo di errore restituito
1533 in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
1534 argomento, \param{option}. Questo è un valore intero che identifica
1535 l'operazione, e deve essere specificato con l'uso di una delle costanti
1536 predefinite del seguente elenco.\footnote{l'elenco potrebbe non risultare
1537 aggiornato, in quanto nuove operazioni vengono aggiunte nello sviluppo del
1538 kernel.} Tratteremo esplicitamente per ciascuna di esse il significato del
1539 il valore di ritorno in caso di successo, ma solo quando non corrisponde
1540 all'ordinario valore nullo (dato per implicito).
1542 %TODO: trattare PR_CAP_AMBIENT, dal 4.3
1543 %TODO: trattare PR_CAP_FP_*, dal 4.0, solo per MIPS
1544 %TODO: trattare PR_MPX_*_MANAGEMENT, dal 3.19
1545 %TODO: trattare PR_*NO_NEW_PRIVS, dal 3.5
1547 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
1548 \item[\constd{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
1549 \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
1550 ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
1551 delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
1552 \textit{capabilities bounding set} del processo e zero altrimenti,
1553 se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
1554 Introdotta a partire dal kernel 2.6.25.
1556 \item[\constd{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
1557 \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
1558 da tutti i suoi discendenti. La funzione cancella la capacità specificata
1559 nell'argomento \param{arg2} con una delle costanti di
1560 tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
1561 processo. L'operazione richiede i privilegi di amministratore (la capacità
1562 \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
1563 \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
1564 per le \textit{file capabilities} non è stato compilato nel kernel la
1565 chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
1568 \item[\constd{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
1569 terminazione di un processo a causa di un segnale per il quale è prevista la
1570 generazione di un file di \textit{core dump} (vedi
1571 sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
1572 viene attivato automaticamente, ma per evitare problemi di sicurezza (la
1573 generazione di un file da parte di processi privilegiati può essere usata
1574 per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
1575 programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
1576 sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
1577 degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
1579 L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
1580 2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
1581 valore 0 (espresso anche come \constd{SUID\_DUMP\_DISABLE}) di \param{arg2}
1582 per disattivare il flag ed un valore 1 (espresso anche come
1583 \constd{SUID\_DUMP\_USER}) per attivarlo. Nei kernel dal 2.6.13 al 2.6.17 è
1584 stato supportato anche il valore 2, che causava la generazione di un
1585 \textit{core dump} leggibile solo dall'amministratore, ma questa
1586 funzionalità è stata rimossa per motivi di sicurezza, in quanto consentiva
1587 ad un utente normale di creare un file di \textit{core dump} appartenente
1588 all'amministratore in directory dove l'utente avrebbe avuto permessi di
1589 accesso. Specificando un valore diverso da 0 o 1 si ottiene un errore di
1592 \item[\constd{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
1593 lo stato corrente del flag che controlla la effettiva generazione dei
1594 \textit{core dump}. Introdotta a partire dal kernel 2.3.20.
1596 \item[\constd{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
1597 chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
1598 sono: \constd{PR\_ENDIAN\_BIG} (\textit{big endian}),
1599 \constd{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
1600 \constd{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
1601 PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
1604 \item[\constd{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
1605 processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
1606 essere passata come di tipo ``\ctyp{int *}''. Introdotta a partire dal
1607 kernel 2.6.18, solo su PowerPC.
1609 \item[\constd{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
1610 della virgola mobile su architettura ia64, secondo il valore
1611 di \param{arg2}, si deve passare \constd{PR\_FPEMU\_NOPRINT} per emulare in
1612 maniera trasparente l'accesso alle operazioni in virgola mobile, o
1613 \constd{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
1614 \signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
1615 dal kernel 2.4.18, solo su architettura ia64.
1617 \item[\constd{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
1618 dell'emulazione della virgola mobile, salvato all'indirizzo puntato
1619 da \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
1620 partire dal kernel 2.4.18, solo su architettura ia64.
1622 \item[\constd{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
1623 mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
1624 I valori possibili sono:
1626 \item \constd{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
1627 \item \constd{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
1628 \item \constd{PR\_FP\_EXC\_OVF} per gli overflow,
1629 \item \constd{PR\_FP\_EXC\_UND} per gli underflow,
1630 \item \constd{PR\_FP\_EXC\_RES} per risultati non esatti,
1631 \item \constd{PR\_FP\_EXC\_INV} per operazioni invalide,
1632 \item \constd{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
1633 \item \constd{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
1634 asincrona non recuperabile,
1635 \item \constd{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
1636 asincrona recuperabile,
1637 \item \constd{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
1638 eccezione.\footnote{trattasi di gestione specialistica della gestione
1639 delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
1640 momento vanno al di là dello scopo di questo testo.}
1642 Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
1644 \item[\constd{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
1645 delle operazioni in virgola mobile, salvata all'indirizzo
1646 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta
1647 a partire dal kernel 2.4.21, solo su PowerPC.
1649 \item[\constd{PR\_SET\_KEEPCAPS}] Consente di controllare quali
1650 \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
1651 \ids{UID} del processo (per i dettagli si veda
1652 sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
1653 pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
1654 per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
1655 mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
1656 L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
1657 flag \const{SECURE\_KEEP\_CAPS} dei \textit{securebits} (vedi
1658 sez.~\ref{sec:proc_capabilities} e l'uso di \const{PR\_SET\_SECUREBITS} più
1659 avanti) e si è impostato con essi \const{SECURE\_KEEP\_CAPS\_LOCKED} si
1660 otterrà un errore di \errval{EPERM}. Introdotta a partire dal kernel
1663 \item[\constd{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
1664 il valore del flag di controllo delle \textit{capabilities} impostato con
1665 \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
1667 \item[\constd{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
1668 stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
1669 nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
1670 terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
1672 \item[\constd{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
1673 stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}'';
1674 si devono allocare per questo almeno 16 byte, e il nome sarà terminato da
1675 NUL se più corto. Introdotta a partire dal kernel 2.6.9.
1677 \item[\constd{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
1678 segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
1679 terminazione del proprio processo padre; in sostanza consente di invertire
1680 il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
1681 numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
1682 automaticamente cancellato per un processo figlio creato con \func{fork}.
1683 Introdotta a partire dal kernel 2.1.57.
1685 \item[\constd{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
1686 emesso alla terminazione del padre, salvato all'indirizzo
1687 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
1688 partire dal kernel 2.3.15.
1690 \item[\constd{PR\_SET\_PTRACER}] Imposta un \ids{PID} per il ``\textit{tracer
1691 process}'' usando \param{arg2}. Una impostazione successiva sovrascrive la
1692 precedente, ed un valore nullo cancella la disponibilità di un
1693 ``\textit{tracer process}''. Questa è una funzionalità fornita da
1694 \textit{``Yama''}, uno specifico \textit{Linux Security Modules}, e serve a
1695 consentire al processo indicato, quando le restrizioni introdotte da questo
1696 modulo sono attive, di usare \func{ptrace} (vedi
1697 sez.~\ref{sec:process_ptrace}) sul processo chiamante, anche se quello
1698 indicato non ne è un progenitore. Il valore \constd{PR\_SET\_PTRACER\_ANY}
1699 consente a tutti i processi l'uso di \func{ptrace}. L'uso si \textit{Yama}
1700 attiene alla gestione della sicurezza dei processi, e consente di introdurre
1701 una restrizione all'uso di \func{ptrace}, che è spesso sorgente di
1702 compromissioni. Si tratta di un uso specialistico che va al di là dello
1703 scopo di queste dispense, per i dettagli si consulti la documentazione su
1704 \textit{Yama} nei sorgenti del kernel. Introdotta a partire dal kernel 3.4.
1706 \item[\constd{PR\_SET\_SECCOMP}] Attiva il \textit{secure computing mode} per
1707 il processo corrente. Introdotta a partire dal kernel 2.6.23 la funzionalità
1708 è stata ulteriormente estesa con il kernel 3.5, salvo poi diventare un
1709 sottoinsieme della \textit{system call} \func{seccomp} a partire dal kernel
1710 3.17. Prevede che si indichi per \param{arg2} il valore
1711 \const{SECCOMP\_MODE\_STRICT} (unico possibile fino al kernel 2.6.23) per
1712 selezionare il cosiddetto \textit{strict mode} o, dal kernel 3.5,
1713 \const{SECCOMP\_MODE\_FILTER} per usare il \textit{filter mode}. Tratteremo
1714 questa opzione nei dettagli più avanti, in sez.~\ref{sec:procadv_seccomp},
1715 quando affronteremo l'argomento del \textit{Secure Computing}.
1717 \item[\constd{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
1718 lo stato corrente del \textit{secure computing mode}. Fino al kernel 3.5,
1719 quando era possibile solo lo \textit{strict mode}, la funzione era
1720 totalmente inutile in quanto l'unico valore ottenibile era 0 in assenza di
1721 \textit{secure computing}, dato che la chiamata di questa funzione in
1722 \textit{strict mode} avrebbe comportato l'emissione di \signal{SIGKILL} per
1723 il chiamante. La funzione però, a partire dal kernel 2.6.23, era stata
1724 comunque definita per eventuali estensioni future, ed infatti con
1725 l'introduzione del \textit{filter mode} con il kernel 3.5, se essa viene
1726 inclusa nelle funzioni consentite restituisce il valore 2 quando il
1727 \textit{secure computing mode} è attivo (se non inclusa si avrà di nuovo un
1730 \item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
1731 processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
1732 significato dei \textit{securebits} si veda
1733 sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
1734 tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
1735 richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
1736 altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
1737 partire dal kernel 2.6.26.
1739 \item[\constd{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
1740 funzione l'impostazione corrente per i \textit{securebits}. Introdotta a
1741 partire dal kernel 2.6.26.
1743 \item[\constd{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
1744 processo da indicare con il valore di \param{arg2}, attualmente i valori
1745 possibili sono due, con \constd{PR\_TIMING\_STATISTICAL} si usa il metodo
1746 statistico tradizionale, con \constd{PR\_TIMING\_TIMESTAMP} il più accurato
1747 basato su dei \textit{timestamp}, quest'ultimo però non è ancora
1748 implementato ed il suo uso comporta la restituzione di un errore di
1749 \errval{EINVAL}. Introdotta a partire dal kernel 2.6.0-test4.
1751 \item[\constd{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
1752 il metodo di temporizzazione del processo attualmente in uso (uno dei due
1753 valori citati per \const{PR\_SET\_TIMING}). Introdotta a partire dal kernel
1756 \item[\constd{PR\_SET\_TSC}] Imposta il flag che indica se il processo
1757 chiamante può leggere il registro di processore contenente il contatore dei
1758 \textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
1759 valore di \param{arg2}. Si deve specificare \constd{PR\_TSC\_ENABLE} per
1760 abilitare la lettura o \constd{PR\_TSC\_SIGSEGV} per disabilitarla con la
1761 generazione di un segnale di \signal{SIGSEGV} (vedi
1762 sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
1763 disabilitata se si attiva il \textit{secure computing mode} (vedi
1764 \const{PR\_SET\_SECCOMP} e sez.~\ref{sec:procadv_seccomp}). Introdotta a
1765 partire dal kernel 2.6.26, solo su x86.
1767 \item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
1768 lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
1769 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
1770 partire dal kernel 2.6.26, solo su x86.
1771 % articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
1772 % http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
1773 % http://en.wikipedia.org/wiki/Time_Stamp_Counter
1775 \item[\constd{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
1776 a indirizzi di memoria non allineati, che in varie architetture risultano
1777 illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
1778 valore \constd{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
1779 ed il valore \constd{PR\_UNALIGN\_SIGBUS} per generare un segnale di
1780 \signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
1781 allineato. Introdotta con diverse versioni su diverse architetture.
1783 \item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
1784 per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
1785 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
1786 diverse versioni su diverse architetture.
1787 \item[\const{PR\_MCE\_KILL}] Imposta la politica di gestione degli errori
1788 dovuti a corruzione della memoria per problemi hardware. Questo tipo di
1789 errori vengono riportati dall'hardware di controllo della RAM e vengono
1790 gestiti dal kernel,\footnote{la funzionalità è disponibile solo sulle
1791 piattaforme più avanzate che hanno il supporto hardware per questo tipo di
1792 controlli.} ma devono essere opportunamente riportati ai processi che
1793 usano quella parte di RAM che presenta errori; nel caso specifico questo
1794 avviene attraverso l'emissione di un segnale di \signal{SIGBUS} (vedi
1795 sez.~\ref{sec:sig_prog_error}).\footnote{in particolare viene anche
1796 impostato il valore di \var{si\_code} in \struct{siginfo\_t} a
1797 \const{BUS\_MCEERR\_AO}; per il significato di tutto questo si faccia
1798 riferimento alla trattazione di sez.~\ref{sec:sig_sigaction}.}
1800 Il comportamento di default prevede che per tutti i processi si applichi la
1801 politica generale di sistema definita nel file
1802 \sysctlfiled{vm/memory\_failure\_early\_kill}, ma specificando
1803 per \param{arg2} il valore \constd{PR\_MCE\_KILL\_SET} è possibile impostare
1804 con il contenuto di \param{arg3} una politica specifica del processo
1805 chiamante. Si può tornare alla politica di default del sistema utilizzando
1806 invece per \param{arg2} il valore \constd{PR\_MCE\_KILL\_CLEAR}. In tutti i
1807 casi, per compatibilità con eventuali estensioni future, tutti i valori
1808 degli argomenti non utilizzati devono essere esplicitamente posti a zero,
1809 pena il fallimento della chiamata con un errore di \errval{EINVAL}.
1811 In caso di impostazione di una politica specifica del processo con
1812 \const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
1813 due, che corrispondono anche al valore che si trova nell'impostazione
1814 generale di sistema di \texttt{memory\_failure\_early\_kill}, con
1815 \constd{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
1816 \signal{SIGBUS} non appena viene rilevato un errore, mentre con
1817 \constd{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
1818 tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
1819 rispettivamente ai valori 1 e 0 di
1820 \texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
1821 viene immediatamente inviato il segnale a tutti i processi che hanno la
1822 memoria corrotta mappata all'interno del loro spazio degli indirizzi, nel
1823 secondo caso prima la pagina di memoria viene tolta dallo spazio degli
1824 indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
1825 processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
1826 terzo valore, \constd{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
1827 per il processo la politica di default.\footnote{si presume la politica di
1828 default corrente, in modo da non essere influenzati da un eventuale
1829 successivo cambiamento della stessa.} Introdotta a partire dal kernel
1831 \item[\constd{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
1832 funzione la politica di gestione degli errori dovuti a corruzione della
1833 memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
1834 nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
1835 partire dal kernel 2.6.32.
1836 \itindbeg{child~reaper}
1837 \item[\constd{PR\_SET\_CHILD\_SUBREAPER}] Se \param{arg2} è diverso da zero
1838 imposta l'attributo di \textit{child reaper} per il processo, se nullo lo
1839 cancella. Lo stato di \textit{child reaper} è una funzionalità, introdotta
1840 con il kernel 3.4, che consente di far svolgere al processo che ha questo
1841 attributo il ruolo di ``\textsl{genitore adottivo}'' per tutti i processi
1842 suoi ``\textsl{discendenti}'' che diventano orfani, in questo modo il
1843 processo potrà ricevere gli stati di terminazione alla loro uscita,
1844 sostituendo in questo ruolo \cmd{init} (si ricordi quanto illustrato in
1845 sez.~\ref{sec:proc_termination}). Il meccanismo è stato introdotto ad uso
1846 dei programmi di gestione dei servizi, per consentire loro di ricevere gli
1847 stati di terminazione di tutti i processi che lanciano, anche se questi
1848 eseguono una doppia \func{fork}; nel comportamento ordinario infatti questi
1849 verrebbero adottati da \cmd{init} ed il programma che li ha lanciati non
1850 sarebbe più in grado di riceverne lo stato di terminazione. Se un processo
1851 con lo stato di \textit{child reaper} termina prima dei suoi discendenti,
1852 svolgerà questo ruolo il più prossimo antenato ad avere lo stato di
1853 \textit{child reaper},
1854 \item[\constd{PR\_GET\_CHILD\_SUBREAPER}] Ottiene l'impostazione relativa allo
1855 lo stato di \textit{child reaper} del processo chiamante, salvata come
1856 \textit{value result} all'indirizzo puntato da \param{arg2} (da indicare
1857 come di tipo \code{int *}). Il valore viene letto come valore logico, se
1858 diverso da 0 lo stato di \textit{child reaper} è attivo altrimenti è
1859 disattivo. Introdotta a partire dal kernel 3.4.
1860 \itindend{child~reaper}
1863 % TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi
1864 % http://lwn.net/Articles/582712/
1866 % TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i
1867 % parametri di base del layout dello spazio di indirizzi di un processo (area
1868 % codice e dati, stack, brack pointer ecc. vedi
1869 % http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e
1871 % TODO documentare ARCH_SET_CPUID e ARCH_GET_CPUID, introdotte con il kernel
1872 % 4.12, vedi https://lwn.net/Articles/721182/
1874 % TODO documentare PR_SPEC_DISABLE_NOEXEC in 5.1, vedi
1875 % https://lwn.net/Articles/782511/
1877 \label{sec:prctl_operation}
1881 \subsection{La funzione \func{ptrace}}
1882 \label{sec:process_ptrace}
1886 % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
1887 % TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
1888 % http://lwn.net/Articles/529060/)
1889 % TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
1891 % TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
1892 % http://lwn.net/Articles/656675/
1894 \subsection{La funzione \func{kcmp}}
1895 \label{sec:process_kcmp}
1897 % TODO: trattare kcmp aggiunta con il kernel 3.5, vedi
1898 % https://lwn.net/Articles/478111/
1899 % vedi man kcmp e man 2 open
1903 \section{La gestione avanzata della creazione dei processi}
1904 \label{sec:process_adv_creation}
1906 In questa sezione tratteremo le funzionalità avanzate relative alla creazione
1907 dei processi e del loro ambiente, sia per quanto riguarda l'utilizzo delle
1908 stesse per la creazione dei \textit{thread} che per la gestione dei
1909 \textit{namespace} che sono alla base dei cosiddetti \textit{container}.
1912 \subsection{La \textit{system call} \func{clone}}
1913 \label{sec:process_clone}
1915 La funzione tradizionale con cui creare un nuovo processo in un sistema
1916 Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
1917 l'introduzione del supporto del kernel per i \textit{thread}\unavref{ (vedi
1918 cap.~\ref{cha:threads})}, si è avuta la necessità di una interfaccia che
1919 consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
1920 processi, che poi è stata utilizzata anche per fornire supporto per le
1921 tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container})
1922 su cui torneremo in sez.~\ref{sec:process_namespaces}.
1924 Per questo l'interfaccia per la creazione di un nuovo processo è stata
1925 delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
1926 di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
1927 più che di nuovi processi si può parlare della creazioni di nuovi
1928 ``\textit{task}'' del kernel che possono assumere la veste sia di un processo
1929 classico isolato dagli altri come quelli trattati finora, che di un
1930 \textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
1931 il nuovo processo creato, come quelli che vedremo in
1932 sez.~\ref{sec:linux_thread}. Per evitare confusione fra \textit{thread} e
1933 processi ordinari, abbiamo deciso di usare la nomenclatura \textit{task} per
1934 indicare la unità di esecuzione generica messa a disposizione del kernel che
1935 \texttt{sys\_clone} permette di creare.
1937 La \textit{system call} richiede soltanto due argomenti: il
1938 primo, \param{flags}, consente di controllare le modalità di creazione del
1939 nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
1940 dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
1941 si intende creare un \textit{thread}. L'esecuzione del programma creato da
1942 \func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
1945 % TODO trattare anche clone3 (vedi https://lwn.net/Articles/792628/), aggiunta
1948 La necessità di avere uno \textit{stack} alternativo c'è solo quando si
1949 intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
1950 vede esattamente la stessa memoria del \textit{task}
1951 ``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
1952 il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
1953 da essa creato, senza nessuna delle implicazioni che il concetto ha per i
1954 processi.} e nella sua esecuzione alla prima chiamata di una funzione
1955 andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
1956 quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
1959 Per evitare di doversi garantire contro la evidente possibilità di
1960 \textit{race condition} che questa situazione comporta (vedi
1961 sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
1962 necessario che il chiamante allochi preventivamente un'area di memoria. In
1963 genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
1964 imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
1965 non utilizzarlo direttamente nel processo chiamante.
1967 In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
1968 non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
1969 presente inoltre che in molte architetture di processore lo \textit{stack}
1970 cresce verso il basso, pertanto in tal caso non si dovrà specificare
1971 per \param{child\_stack} il puntatore restituito da \func{malloc}, ma un
1972 puntatore alla fine del buffer da essa allocato.
1974 Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
1975 memoria, la \textit{system call}, a differenza della funzione di libreria che
1976 vedremo a breve, consente anche di passare per \param{child\_stack} il valore
1977 \val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
1978 processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
1979 cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
1980 in questo caso si applica la semantica del \textit{copy on write} illustrata
1981 in sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
1982 automaticamente copiate come le altre e il nuovo processo avrà un suo
1983 \textit{stack} totalmente indipendente da quello del padre.
1985 Dato che l'uso principale della nuova \textit{system call} è quello relativo
1986 alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
1987 libreria con una sintassi diversa, orientata a questo scopo, e la
1988 \textit{system call} resta accessibile solo se invocata esplicitamente come
1989 visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
1990 \textit{system call} non è disponibile la chiamata veloce con
1991 \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
1992 \funcd{clone} ed il suo prototipo è:
1996 \fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
1998 \phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
1999 \fdesc{Crea un nuovo processo o \textit{thread}.}
2001 {La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
2002 di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
2005 \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
2006 \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
2007 un valore nullo per \param{child\_stack}.
2008 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
2009 \texttt{task\_struct} o per copiare le parti del contesto del chiamante
2010 necessarie al nuovo \textit{task}.
2011 \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
2012 richiesti dai flag indicati.
2016 % NOTE: una pagina con la descrizione degli argomenti:
2017 % * http://www.lindevdoc.org/wiki/Clone
2019 La funzione prende come primo argomento \param{fn} il puntatore alla funzione
2020 che verrà messa in esecuzione nel nuovo processo, che può avere un unico
2021 argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
2022 terzo argomento \param{arg}. Per quanto il precedente prototipo possa
2023 intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
2024 definire una qualunque funzione \param{fn} che restituisce un intero ed ha
2025 come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
2028 Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
2029 non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
2030 di ritorno della funzione (o quello specificato con \func{exit}) verrà
2031 utilizzato come stato di uscita della funzione. I tre
2032 argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
2033 presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
2034 le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
2035 Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
2036 utilizzati soltanto se si sono specificati rispettivamente i flag
2037 \const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
2038 \const{CLONE\_CHILD\_SETTID}.
2040 La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
2041 \textit{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
2042 al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
2043 un processo ordinario e non un \textit{thread}.
2045 Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
2046 nuovo processo da essa creato, è controllato principalmente
2047 dall'argomento \param{flags}, che deve essere specificato come maschera
2048 binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
2049 elenco, che illustra quelle attualmente disponibili:\footnote{si fa
2050 riferimento al momento della stesura di questa sezione, cioè con il kernel
2053 \begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
2055 \item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
2056 ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un
2057 riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a
2058 quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei
2059 \textit{thread} ed è presente dal kernel 2.5.49.
2061 \item[\constd{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
2062 figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
2063 utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
2066 \item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
2067 padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
2068 questo significa che ogni \textit{file descriptor} aperto da un processo
2069 verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
2070 \textit{file descriptor flags} di un \textit{file descriptor} verrà per
2073 Se non viene impostato il processo figlio eredita una copia della
2074 \textit{file descriptor table} del padre e vale la semantica classica della
2075 gestione dei \textit{file descriptor}, che costituisce il comportamento
2076 ordinario di un sistema unix-like e che illustreremo in dettaglio in
2077 sez.~\ref{sec:file_shared_access}.
2079 \item[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
2080 condividerà con il padre le informazioni relative all'albero dei file, ed in
2081 particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
2082 stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
2083 \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
2084 qualunque di queste caratteristiche in un processo, avrà effetto anche
2085 sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
2086 informazioni, che saranno così indipendenti per i due processi, come avviene
2087 nel comportamento ordinario di un sistema unix-like.
2089 \item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo processo
2090 condividerà con il padre il contesto dell'I/O, altrimenti, come avviene nel
2091 comportamento ordinario con una \func{fork} otterrà un suo contesto
2094 Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
2095 sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
2096 questi vengono trattati come se fossero lo stesso, condividendo il tempo per
2097 l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
2098 questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
2099 dello stesso processo (ad esempio con le funzioni di I/O asincrono di
2100 sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
2102 %TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
2103 %relativa sezione da creare a parte
2105 % \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
2106 % introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
2107 % processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
2108 % di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
2109 % di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
2110 % tutti quegli oggetti che non vegono identificati con un \textit{pathname}
2111 % sull'albero dei file.
2113 % L'uso di questo flag richiede privilegi di amministratore (più precisamente
2114 % la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
2115 % con \const{CLONE\_SYSVSEM}.
2117 % \item[\constd{CLONE\_NEWNET}]
2118 % \item[\constd{CLONE\_NEWNS}]
2119 % \item[\constd{CLONE\_NEWPID}]
2120 % \item[\constd{CLONE\_NEWUTS}]
2123 % TODO trattare CLONE_NEWCGROUP introdotto con il kernel 4.6, vedi
2124 % http://lwn.net/Articles/680566/
2126 \item[\constd{CLONE\_PARENT}]
2127 \item[\constd{CLONE\_PARENT\_SETTID}]
2128 \item[\constd{CLONE\_PID}]
2130 % TODO trattare CLONE_PIDFD introdotto con il kernel 5.2, vedi
2131 % https://lwn.net/Articles/787963/ e anche https://lwn.net/Articles/789023/
2133 \item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
2134 chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
2135 figlio viene tracciato.
2137 \item[\constd{CLONE\_SETTLS}]
2138 \item[\constd{CLONE\_SIGHAND}]
2139 \item[\constd{CLONE\_STOPPED}]
2140 \item[\constd{CLONE\_SYSVSEM}]
2141 \item[\constd{CLONE\_THREAD}]
2143 \item[\constd{CLONE\_UNTRACED}] se questo flag viene impostato un processo non
2144 può più forzare \const{CLONE\_PTRACE} su questo processo.
2146 \item[\constd{CLONE\_VFORK}] se questo flag viene impostato il chiamante viene
2147 fermato fintato che il figlio appena creato non rilascia la sua memoria
2148 virtuale con una chiamata a \func{exec} o \func{exit}, viene quindi
2149 replicato il comportamento di \func{vfork}.
2151 \item[\constd{CLONE\_VM}] se questo flag viene impostato il nuovo processo
2152 condividerà con il padre la stessa memoria virtuale, e le scritture in
2153 memoria fatte da uno qualunque dei processi saranno visibili dall'altro,
2154 così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}).
2156 Se non viene impostato il processo figlio otterrà una copia dello spazio
2157 degli indirizzi e si otterrà il comportamento ordinario di un processo di un
2158 sistema unix-like creato con la funzione \func{fork}.
2163 \subsection{La gestione dei \textit{namespace}}
2164 \label{sec:process_namespaces}
2166 \itindbeg{namespace}
2167 Come accennato all'inizio di sez.~\ref{sec:process_clone} oltre al controllo
2168 delle caratteristiche dei processi usate per la creazione dei \textit{thread},
2169 l'uso di \func{clone} consente, ad uso delle nuove funzionalità di
2170 virtualizzazione dei processi, di creare nuovi ``\textit{namespace}'' per una
2171 serie di proprietà generali (come l'elenco dei \ids{PID}, l'albero dei file, i
2172 \textit{mount point}, la rete, il sistema di IPC, ecc.).
2174 L'uso dei ``\textit{namespace}'' consente creare gruppi di processi che vedono
2175 le suddette proprietà in maniera indipendente fra loro. I processi di ciascun
2176 gruppo vengono così eseguiti come in una sorta di spazio separato da quello
2177 degli altri gruppi, che costituisce poi quello che viene chiamato un
2180 \itindend{namespace}
2183 \itindbeg{container}
2185 \itindend{container}
2188 %TODO sezione separata sui namespace
2190 %TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
2192 %TODO: trattare la funzione setns e i namespace file descriptors (vedi
2193 % http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
2194 % informazioni su setns qui: http://lwn.net/Articles/532748/
2195 % http://lwn.net/Articles/531498/
2197 % TODO: se si applicano e ci stanno trattare gli argomenti di ioctl_ns
2199 \section{Funzionalità avanzate e specialistiche}
2200 \label{sec:process_special}
2203 % TODO: trattare userfaultfd, introdotta con il 4.23, vedi
2204 % http://man7.org/linux/man-pages/man2/userfaultfd.2.html
2206 % TODO: trattare process_vm_readv/process_vm_writev introdotte con il kernel
2207 % 3.2, vedi http://man7.org/linux/man-pages/man2/process_vm_readv.2.html e i
2208 % precedenti tentativi https://lwn.net/Articles/405346/
2211 \subsection{La gestione delle operazioni in virgola mobile}
2212 \label{sec:process_fenv}
2216 % TODO eccezioni ed arrotondamenti per la matematica in virgola mobile
2217 % consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater,
2218 % isnan, nan, INFINITY
2221 \subsection{L'accesso alle porte di I/O}
2222 \label{sec:process_io_port}
2225 % TODO l'I/O sulle porte di I/O
2226 % consultare le manpage di ioperm, iopl e outb
2227 % non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
2233 %\subsection{La gestione di architetture a nodi multipli}
2234 %\label{sec:process_NUMA}
2236 % TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati
2237 % per associare l'uso di gruppi di processori a gruppi di processi (vedi
2239 % TODO trattare getcpu, che attiene anche a NUMA, mettere qui anche
2240 % sched_getcpu, che potrebbe essere indipendente ma richiama getcpu
2242 %TODO trattare le funzionalità per il NUMA
2243 % vedi man numa e, mbind, get_mempolicy, set_mempolicy,
2244 % le pagine di manuale relative
2245 % vedere anche dove metterle...
2247 % \subsection{La gestione dei moduli}
2248 % \label{sec:kernel_modules}
2252 %TODO trattare init_module e finit_module (quest'ultima introdotta con il
2255 %%%% Altre cose di cui non è chiara la collocazione:
2257 %TODO trattare membarrier, introdotta con il kernel 4.3
2258 % vedi http://lwn.net/Articles/369567/ http://lwn.net/Articles/369640/
2259 % http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b25b13ab08f616efd566347d809b4ece54570d1
2260 % vedi anche l'ulteriore opzione "expedited" introdotta con il kernel 4.14
2261 % (https://lwn.net/Articles/728795/)
2265 %%% Local Variables:
2267 %%% TeX-master: "gapil"
2270 % LocalWords: system call namespace prctl IRIX kernel sys int option long
2271 % LocalWords: unsigned arg errno EACCESS EBADF EBUSY EFAULT EINVAL ENXIO PR
2272 % LocalWords: EOPNOTSUPP EPERM CAPBSET READ capability sez tab capabilities
2273 % LocalWords: bounding CAP SETPCAP DUMPABLE dump suid sgid UID DISABLE GET
2274 % LocalWords: ENDIAN endianness BIG big endian LITTLE little PPC PowerPC ia
2275 % LocalWords: FPEMU NOPRINT SIGFPE FPEXC point exception FP EXC SW ENABLE
2276 % LocalWords: OVF overflow UND underflow RES INV DISABLED NONRECOV ASYNC AO
2277 % LocalWords: KEEPCAPS pag exec SECURE KEEP CAPS securebits LOCKED NAME NUL
2278 % LocalWords: char PDEATHSIG SIGCHLD fork PTRACER PID tracer process ptrace
2279 % LocalWords: Security Modules ANY Yama SECCOMP secure computing seccomp vm
2280 % LocalWords: STRICT strict FILTER filter SIGKILL TIMING STATISTICAL TSC fn
2281 % LocalWords: TIMESTAMP timestamp Stamp Counter SIGSEGV UNALIGN SIGBUS MCE
2282 % LocalWords: KILL siginfo MCEERR memory failure early kill CLEAR child cap
2283 % LocalWords: reaper SUBREAPER init value result thread like flags stack FS
2284 % LocalWords: race condition malloc NULL copy write glibc vsyscall sched RT
2285 % LocalWords: void pid ptid struct desc tls ctid EAGAIN ENOMEM exit Posix
2286 % LocalWords: Library PARENT SETTID SETTLS TID CLEARTID futex FILES table
2287 % LocalWords: descriptor umask dell'I scheduler SIGHAND STOPPED SYSVSEM IPC
2288 % LocalWords: UNTRACED VFORK vfork mount filesystem LSM Mandatory Access fs
2289 % LocalWords: Control DAC MAC SELinux Smack Tomoyo AppArmor Discrectionary
2290 % LocalWords: permitted inheritable effective fig security ADMIN forced new
2291 % LocalWords: allowed dall' bound MODULE nell' all' capset sendmail SETGID
2292 % LocalWords: setuid orig IMMUTABLE MKNOD OVERRIDE SEARCH CHOWN FSETID LOCK
2293 % LocalWords: FOWNER saved FIXUP NOROOT AUDIT BLOCK SUSPEND SETFCAP group
2294 % LocalWords: socket domain locking mlock mlockall shmctl mmap OWNER LEASE
2295 % LocalWords: lease immutable append only mknod BIND SERVICE BROADCAST RAW
2296 % LocalWords: broadcast multicast PACKET CHROOT chroot NICE PACCT RAWIO TTY
2297 % LocalWords: accounting ioperm iopl RESOURCE CONFIG hangup vhangup SYSLOG
2298 % LocalWords: WAKE ALARM CLOCK BOOTTIME REALTIME sticky NOATIME fcntl swap
2299 % LocalWords: multicasting dell'IPC SysV trusted IOPRIO CLASS IDLE lookup
2300 % LocalWords: scheduling dcookie NEWNS unshare nice NUMA ioctl journaling
2301 % LocalWords: ext capget header hdrp datap const ESRCH SOURCE undef version
2302 % LocalWords: libcap lcap obj to text dup clear DIFFERS get ncap caps ssize
2303 % LocalWords: argument length all setpcap from string name proc cat capgetp
2304 % LocalWords: capsetp getcap read sigreturn sysctl protected hardlinks tmp
2305 % LocalWords: dell' symlink symlinks pathname TOCTTOU of execve attack kcmp