From: Simone Piccardi Date: Sat, 23 May 2015 22:08:07 +0000 (+0000) Subject: Revisionati gli errori di mmap e risistemate alcune indicizzazioni (ed X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=936ae71ad2a06b154b23470ef38f477af32e67fe;p=gapil.git Revisionati gli errori di mmap e risistemate alcune indicizzazioni (ed inserito paragrafetto su DAC e MAC) --- diff --git a/fileadv.tex b/fileadv.tex index bd3063a..e531364 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -3950,8 +3950,8 @@ prototipo è: } {La funzione ritorna il puntatore alla zona di memoria mappata in caso di - successo, e \const{MAP\_FAILED} ($-1$) per un errore, nel qual caso - \var{errno} assumerà uno dei valori: + successo, e \const{MAP\_FAILED} (\texttt{(void *) -1}) per un errore, nel + qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare, o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura, @@ -3965,13 +3965,19 @@ prototipo è: \const{MAP\_ANONYMOUS}. \item[\errcode{EINVAL}] i valori di \param{start}, \param{length} o \param{offset} non sono validi (o troppo grandi o non allineati sulla - dimensione delle pagine). + dimensione delle pagine), o \param{lengh} è zero (solo dal 2.6.12) + o \param{flags} contiene sia \const{MAP\_PRIVATE} che + \const{MAP\_SHARED} o nessuno dei due. \item[\errcode{ENFILE}] si è superato il limite del sistema sul numero di file aperti (vedi sez.~\ref{sec:sys_resource_limit}). \item[\errcode{ENODEV}] il filesystem di \param{fd} non supporta il memory mapping. \item[\errcode{ENOMEM}] non c'è memoria o si è superato il limite sul numero di mappature possibili. + \item[\errcode{EOVERFLOW}] su architettura a 32 bit con il supporto per i + \textit{large file} (che hanno una dimensione a 64 bit) il numero di + pagine usato per \param{lenght} aggiunto a quello usato + per \param{offset} eccede i 32 bit (\texttt{unsigned long}). \item[\errcode{EPERM}] l'argomento \param{prot} ha richiesto \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con l'opzione \texttt{noexec}. @@ -3981,14 +3987,14 @@ prototipo è: } \end{funcproto} - La funzione richiede di mappare in memoria la sezione del file \param{fd} a partire da \param{offset} per \param{length} byte, preferibilmente all'indirizzo \param{start}. Il valore \param{start} viene normalmente -considerato come un suggerimento, ma l'uso di un valore diverso da \val{NULL}, -in cui si rimette completamente al kernel la scelta dell'indirizzo, viene -sconsigliato per ragioni di portabilità. Il valore di \param{offset} deve -essere un multiplo della dimensione di una pagina di memoria. +considerato come un suggerimento, ma l'uso di un qualunque valore diverso da +\val{NULL}, in cui si rimette completamente al kernel la scelta +dell'indirizzo, viene sconsigliato per ragioni di portabilità. Il valore +di \param{offset} deve essere un multiplo della dimensione di una pagina di +memoria. \begin{table}[htb] \centering @@ -4063,13 +4069,13 @@ tab.~\ref{tab:file_mmap_flag}. con gli indirizzi crescenti verso il basso.\\ \const{MAP\_HUGETLB} & Esegue la mappatura usando le cosiddette ``\textit{huge pages}'' (dal 2.6.32).\\ - \const{MAP\_LOCKED} & Se impostato impedisce lo \textit{swapping} delle pagine - mappate (dal 2.5.37).\\ + \const{MAP\_LOCKED} & Se impostato impedisce lo \textit{swapping} delle + pagine mappate (dal 2.5.37).\\ \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che non causa I/O (dal 2.5.46).\\ \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva - delle pagine di \textit{swap} ad uso del meccanismo del - \textit{copy on write} \itindex{copy~on~write} + delle pagine di \textit{swap} ad uso del meccanismo + del \textit{copy on write} \itindex{copy~on~write} per mantenere le modifiche fatte alla regione mappata, in questo caso dopo una scrittura, se non c'è più memoria disponibile, si ha @@ -4142,25 +4148,22 @@ effettive del file o della sezione che si vuole mappare. Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei confini di una pagina: in tal caso verrà il file sarà mappato su un segmento di memoria che si estende fino al -bordo della pagina successiva. - -In questo caso è possibile accedere a quella zona di memoria che eccede le -dimensioni specificate da \param{length}, senza ottenere un \signal{SIGSEGV} -poiché essa è presente nello spazio di indirizzi del processo, anche se non è -mappata sul file. Il comportamento del sistema è quello di restituire un -valore nullo per quanto viene letto, e di non riportare su file quanto viene -scritto. +bordo della pagina successiva. In questo caso è possibile accedere a quella +zona di memoria che eccede le dimensioni specificate da \param{length}, senza +ottenere un \signal{SIGSEGV} poiché essa è presente nello spazio di indirizzi +del processo, anche se non è mappata sul file. Il comportamento del sistema è +quello di restituire un valore nullo per quanto viene letto, e di non +riportare su file quanto viene scritto. Un caso più complesso è quello che si viene a creare quando le dimensioni del file mappato sono più corte delle dimensioni della mappatura, oppure quando il file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a -quella della mappatura in memoria. - -In questa situazione, per la sezione di pagina parzialmente coperta dal -contenuto del file, vale esattamente quanto visto in precedenza; invece per la -parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non -sarà più possibile, ma il segnale emesso non sarà \signal{SIGSEGV}, ma -\signal{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}. +quella della mappatura in memoria. In questa situazione, per la sezione di +pagina parzialmente coperta dal contenuto del file, vale esattamente quanto +visto in precedenza; invece per la parte che eccede, fino alle dimensioni date +da \param{length}, l'accesso non sarà più possibile, ma il segnale emesso non +sarà \signal{SIGSEGV}, ma \signal{SIGBUS}, come illustrato in +fig.~\ref{fig:file_mmap_exceed}. Non tutti i file possono venire mappati in memoria, dato che, come illustrato in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza diff --git a/filedir.tex b/filedir.tex index e174c5b..b568af7 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1095,8 +1095,8 @@ prototipo è: \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. } \end{funcproto} -\footnotetext{più precisamente la \itindex{capabilities} capacità - \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}.} +\footnotetext{più precisamente la capacità \const{CAP\_SYS\_ADMIN}, vedi + sez.~\ref{sec:proc_capabilities}.} La funzione prende il nome della directory su cui il filesystem è montato e non il file o il dispositivo che è stato montato,\footnote{questo è vero a @@ -2715,16 +2715,15 @@ Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo valore verrà ignorato. Solo l'amministratore può creare un file di -dispositivo usando questa funzione (il processo deve avere la -\itindex{capabilities} \textit{capability} \const{CAP\_MKNOD}), ma in -Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è - prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e - 4.4BSD, ma esistono differenze nei comportamenti e nei codici di errore, - tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la - definisce portabile solo quando viene usata per creare delle fifo, ma - comunque deprecata essendo utilizzabile a tale scopo la specifica - \func{mkfifo}.} l'uso per la creazione di un file ordinario, di una fifo o -di un socket è consentito anche agli utenti normali. +dispositivo usando questa funzione (il processo deve avere la capacità +\const{CAP\_MKNOD}), ma in Linux\footnote{questo è un comportamento specifico + di Linux, la funzione non è prevista dallo standard POSIX.1 originale, + mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti + e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001 + con una nota che la definisce portabile solo quando viene usata per creare + delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la + specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di +una fifo o di un socket è consentito anche agli utenti normali. I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno al proprietario e al gruppo del processo (usando \ids{UID} e \ids{GID} del @@ -3643,7 +3642,7 @@ tempo corrente ed è sufficiente avere accesso in scrittura al file o essere proprietari del file o avere i privilegi di amministratore. Se invece si è specificato un valore diverso la funzione avrà successo solo se si è proprietari del file o se si hanno i privilegi di amministratore.\footnote{per - essere precisi la \itindex{capabilities} capacità \const{CAP\_FOWNER}, vedi + essere precisi la capacità \const{CAP\_FOWNER}, vedi sez.~\ref{sec:proc_capabilities}.} In entrambi i casi per verificare la proprietà del file viene utilizzato l'\ids{UID} effettivo del processo. @@ -3874,15 +3873,14 @@ campo \var{st\_gid} della omonima struttura \struct{stat}. Il controllo di accesso ai file segue un modello abbastanza semplice che prevede tre permessi fondamentali strutturati su tre livelli di accesso. -Esistono varie estensioni a questo modello,\footnote{come le - \itindex{Access~Control~List~(ACL)} \textit{Access Control List} che sono - state aggiunte ai filesystem standard con opportune estensioni (vedi - sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di controllo ancora più - sofisticati come il \itindex{Mandatory~Access~Control~(MAC)} - \textit{mandatory access control} di SE-Linux e delle altre estensioni come - \textit{Smack} o \textit{AppArmor}.} ma nella maggior parte dei casi il -meccanismo standard è più che sufficiente a soddisfare tutte le necessità più -comuni. I tre permessi di base associati ad ogni file sono: +Esistono varie estensioni a questo modello,\footnote{come le \textit{Access + Control List} che sono state aggiunte ai filesystem standard con opportune + estensioni (vedi sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di + controllo ancora più sofisticati come il \textit{Mandatory Access Control} + di \textit{SELinux} e delle altre estensioni come \textit{Smack} o + \textit{AppArmor}.} ma nella maggior parte dei casi il meccanismo standard è +più che sufficiente a soddisfare tutte le necessità più comuni. I tre +permessi di base associati ad ogni file sono: \begin{itemize*} \item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese \textit{read}). @@ -4109,7 +4107,7 @@ Entrambi questi attributi attivano queste restrizioni a livello di filesystem, per cui a differenza dei permessi ordinari esse varranno per qualunque utente compreso l'amministratore. L'amministratore è l'unico che può attivare o disattivare questi attributi,\footnote{più precisamente un processo con la - \itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi + capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi sez.~\ref{sec:proc_capabilities}.} e potendo rimuoverli è comunque capace di tornare in grado di eseguire qualunque operazione su un file immutabile o \textit{append-only}. @@ -4456,10 +4454,10 @@ misura di sicurezza, volta a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai permessi di un file qualora un processo che non appartenga all'amministratore\footnote{per la precisione un processo che non dispone - della \itindex{capabilities} capacità \const{CAP\_FSETID}, vedi - sez.~\ref{sec:proc_capabilities}.} effettui una scrittura. In questo modo -anche se un utente malizioso scopre un file \acr{suid} su cui può scrivere, -un'eventuale modifica comporterà la perdita di questo privilegio. + della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} +effettui una scrittura. In questo modo anche se un utente malizioso scopre un +file \acr{suid} su cui può scrivere, un'eventuale modifica comporterà la +perdita di questo privilegio. Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i permessi di un file, resta però il problema di quali sono i permessi assegnati @@ -4595,14 +4593,14 @@ prototipi sono: Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori specificati dalle variabili \param{owner} e \param{group}. Con Linux solo -l'amministratore\footnote{o in generale un processo con la - \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi - sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file; -in questo viene seguita la semantica usata da BSD che non consente agli utenti -di assegnare i loro file ad altri utenti evitando eventuali aggiramenti delle -quote. L'amministratore può cambiare sempre il gruppo di un file, il -proprietario può cambiare il gruppo solo dei file che gli appartengono e solo -se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte. +l'amministratore\footnote{o in generale un processo con la capacità + \const{CAP\_CHOWN}, vedi sez.~\ref{sec:proc_capabilities}.} può cambiare il +proprietario di un file; in questo viene seguita la semantica usata da BSD che +non consente agli utenti di assegnare i loro file ad altri utenti evitando +eventuali aggiramenti delle quote. L'amministratore può cambiare sempre il +gruppo di un file, il proprietario può cambiare il gruppo solo dei file che +gli appartengono e solo se il nuovo gruppo è il suo gruppo primario o uno dei +gruppi di cui fa parte. La funzione \func{chown} segue i collegamenti simbolici, per operare direttamente su un collegamento simbolico si deve usare la funzione @@ -4753,12 +4751,11 @@ Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche Linux) hanno introdotto un meccanismo generico, detto \textit{Extended Attributes} che consente di associare delle informazioni ulteriori ai singoli file.\footnote{essi ad esempio vengono usati per le ACL, che - tratteremo in sez.~\ref{sec:file_ACL} e le \itindex{file~capabilities} - \textit{file capabilities}, che vedremo in - sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi} non sono -altro che delle coppie nome/valore che sono associate permanentemente ad un -oggetto sul filesystem, analoghi di quello che sono le variabili di ambiente -(vedi sez.~\ref{sec:proc_environ}) per un processo. + tratteremo in sez.~\ref{sec:file_ACL} e le \textit{file capabilities}, che + vedremo in sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi} +non sono altro che delle coppie nome/valore che sono associate permanentemente +ad un oggetto sul filesystem, analoghi di quello che sono le variabili di +ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo. Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo diverso in cui ad un file sono associati diversi flussi di dati, su cui @@ -4815,15 +4812,13 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. \hline \texttt{security}&Gli \textit{extended security attributes}: vengono utilizzati dalle estensioni di sicurezza del kernel (i - \itindex{Linux~Security~Modules} \textit{Linux - Security Modules}), per le realizzazione di meccanismi - evoluti di controllo di accesso come \index{SELinux} - SELinux o le \textit{capabilities} dei file di - sez.~\ref{sec:proc_capabilities}.\\ + \textit{Linux Security Modules}), per le realizzazione + di meccanismi evoluti di controllo di accesso come + \textit{SELinux} o le \textit{capabilities} dei + file di sez.~\ref{sec:proc_capabilities}.\\ \texttt{system} & Gli \textit{extended security attributes}: sono usati dal kernel per memorizzare dati di sistema associati ai - file come le \itindex{Access~Control~List~(ACL)} ACL (vedi - sez.~\ref{sec:file_ACL}) o le \itindex{capabilities} + file come le ACL (vedi sez.~\ref{sec:file_ACL}) o le \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}).\\ \texttt{trusted}& I \textit{trusted extended attributes}: vengono @@ -4844,43 +4839,40 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per -realizzare delle estensioni (come le \itindex{Access~Control~List~(ACL)} ACL, -\index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli di -accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa a -seconda sia della loro classe che di quali, fra le estensioni che li -utilizzano, sono poste in uso. In particolare, per ciascuna delle classi -riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti -casi: +realizzare delle estensioni (come le ACL, \textit{SELinux}, ecc.) al +tradizionale meccanismo dei controlli di accesso di Unix, l'accesso ai loro +valori viene regolato in maniera diversa a seconda sia della loro classe che +di quali, fra le estensioni che li utilizzano, sono poste in uso. In +particolare, per ciascuna delle classi riportate in +tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}} \item[\texttt{security}] L'accesso agli \textit{extended security attributes} dipende dalle politiche di sicurezza stabilite da loro stessi tramite - l'utilizzo di un sistema di controllo basato sui - \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio - \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende - dalle politiche di sicurezza implementate all'interno dal modulo di - sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è - stato caricato nessun modulo di sicurezza l'accesso in lettura sarà - consentito a tutti i processi, mentre quello in scrittura solo ai processi - con privilegi amministrativi dotati della \itindex{capabilities} - \textit{capability} \const{CAP\_SYS\_ADMIN}. + l'utilizzo di un sistema di controllo basato sui \textit{Linux Security + Modules} (ad esempio \textit{SELinux}). Pertanto l'accesso in lettura o + scrittura dipende dalle politiche di sicurezza implementate all'interno dal + modulo di sicurezza che si sta utilizzando al momento (ciascuno avrà le + sue). Se non è stato caricato nessun modulo di sicurezza l'accesso in + lettura sarà consentito a tutti i processi, mentre quello in scrittura solo + ai processi con privilegi amministrativi dotati della capacità + \const{CAP\_SYS\_ADMIN}. \item[\texttt{system}] Anche l'accesso agli \textit{extended system attributes} dipende dalle politiche di accesso che il kernel realizza anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso - delle \itindex{Access~Control~List~(ACL)} ACL l'accesso è consentito in - lettura ai processi che hanno la capacità di eseguire una ricerca sul file - (cioè hanno il permesso di lettura sulla directory che contiene il file) ed - in scrittura al proprietario del file o ai processi dotati della - \textit{capability} \itindex{capabilities} + delle ACL (vedi sez.~\ref{sec:file_ACL}) l'accesso è consentito in lettura + ai processi che hanno la capacità di eseguire una ricerca sul file (cioè + hanno il permesso di lettura sulla directory che contiene il file) ed in + scrittura al proprietario del file o ai processi dotati della capacità \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a quella impiegata per gli ordinari permessi dei file.} \item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia per la lettura che per la scrittura, è consentito soltanto ai processi con - privilegi amministrativi dotati della \itindex{capabilities} - \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono - utilizzare questi attributi per realizzare in user space dei meccanismi di - controllo che accedono ad informazioni non disponibili ai processi ordinari. + privilegi amministrativi dotati della capacità \const{CAP\_SYS\_ADMIN}. In + questo modo si possono utilizzare questi attributi per realizzare in user + space dei meccanismi di controllo che accedono ad informazioni non + disponibili ai processi ordinari. \item[\texttt{user}] L'accesso agli \textit{extended user attributes} è regolato dai normali permessi dei file: occorre avere il permesso di lettura @@ -4919,8 +4911,7 @@ casi: per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit} \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended user attributes} soltanto se si è proprietari della stessa, o si hanno i - privilegi amministrativi della capacità \itindex{capabilities} - \const{CAP\_FOWNER}. + privilegi amministrativi della capacità \const{CAP\_FOWNER}. \end{basedescript} Le funzioni per la gestione degli attributi estesi, come altre funzioni di @@ -5187,7 +5178,7 @@ può impostare una ACL aggiuntiva, detta ``\textit{Default ACL}'', che serve ad indicare quale dovrà essere la ACL assegnata di default nella creazione di un file all'interno della directory stessa. Come avviene per i permessi le ACL possono essere impostate solo del proprietario del file, o da un processo con -la capacità \itindex{capabilities} \const{CAP\_FOWNER}. +la capacità \const{CAP\_FOWNER}. \begin{table}[htb] \centering @@ -5305,9 +5296,9 @@ quali viene stabilito se il processo ha il diritto di accesso sono i seguenti: \begin{enumerate} \item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore) l'accesso è sempre garantito senza nessun controllo.\footnote{più - precisamente se si devono avere le \itindex{capabilities} capacità - \const{CAP\_DAC\_OVERRIDE} per i file e \const{CAP\_DAC\_READ\_SEARCH} per - le directory, vedi sez.~\ref{sec:proc_capabilities}.} + precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per + i file e \const{CAP\_DAC\_READ\_SEARCH} per le directory, vedi + sez.~\ref{sec:proc_capabilities}.} \item Se l'\ids{UID} del processo corrisponde al proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, @@ -6159,7 +6150,7 @@ significato delle operazioni associate a ciascuno di essi. In generale le operazioni di attivazione, disattivazione e di modifica dei limiti delle quote sono riservate e richiedono i privilegi di amministratore.\footnote{per essere precisi tutte le operazioni indicate come privilegiate in - tab.~\ref{tab:quotactl_commands} richiedono la \textit{capability} + tab.~\ref{tab:quotactl_commands} richiedono la capacità \const{CAP\_SYS\_ADMIN}.} Inoltre gli utenti possono soltanto richiedere i dati relativi alle proprie quote, solo l'amministratore può ottenere i dati di tutti. @@ -6413,13 +6404,12 @@ Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della gestione dei privilegi in un sistema unix-like ha il sostanziale problema di fornire all'amministratore dei poteri troppo ampi. Questo comporta che anche quando si siano predisposte delle misure di protezione per in essere in grado -di difendersi dagli effetti di una eventuale compromissione del -sistema,\footnote{come montare un filesystem in sola lettura per impedirne - modifiche, o marcare un file come immutabile.} una volta che questa sia -stata effettuata e si siano ottenuti i privilegi di amministratore, queste -misure potranno essere comunque rimosse.\footnote{nei casi elencati nella - precedente nota si potrà sempre rimontare il sistema in lettura-scrittura, o - togliere l'attributo di immutabilità.} +di difendersi dagli effetti di una eventuale compromissione del sistema (come +montare un filesystem in sola lettura per impedirne modifiche, o marcare un +file come immutabile) una volta che questa sia stata effettuata e si siano +ottenuti i privilegi di amministratore, queste misure potranno essere comunque +rimosse (nei casi elencati nella precedente nota si potrà sempre rimontare il +sistema in lettura-scrittura, o togliere l'attributo di immutabilità). Il problema consiste nel fatto che nell'architettura tradizionale di un sistema unix-like i controlli di accesso sono basati su un solo livello di @@ -6427,9 +6417,22 @@ separazione: per i processi normali essi sono posti in atto, mentre per i processi con i privilegi di amministratore essi non vengono neppure eseguiti. Per questo motivo non era previsto alcun modo per evitare che un processo con diritti di amministratore non potesse eseguire certe operazioni, o per cedere -definitivamente alcuni privilegi da un certo momento in poi. - -Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato +definitivamente alcuni privilegi da un certo momento in poi. + +Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai +kernel 2.5 è stata introdotta la struttura dei +\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han +permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)} +\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e +controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi +possono essere usati dai programmi e trasferiti agli utenti, con la creazione +di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo}, +\textit{AppArmor}) che consentono di superare l'architettura tradizionale dei +permessi basati sul modello classico del controllo di accesso chiamato +\itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access + Control} (DAC). + +Ma già in precedenza, a partire dai kernel della serie 2.2, era stato introdotto un meccanismo, detto \textit{capabilities}, che consentisse di suddividere i vari privilegi tradizionalmente associati all'amministratore in un insieme di \textsl{capacità} distinte. L'idea era che queste capacità @@ -6440,18 +6443,17 @@ originaria di ``\textsl{tutto o nulla}''. \itindbeg{file~capabilities} -Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione - si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e, - poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai -singoli file eseguibili, in modo da poter stabilire quali capacità possono -essere utilizzate quando viene messo in esecuzione uno specifico programma; ma -il supporto per questa funzionalità, chiamata \textit{file capabilities}, è -stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva -essere il programma stesso ad eseguire una riduzione esplicita delle sue -capacità, cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la -presenza di meccanismi alternativi per ottenere limitazioni delle capacità -dell'amministratore a livello di sistema operativo, come \index{SELinux} -SELinux. +Il meccanismo completo delle \textit{capabilities} (l'implementazione si rifà +ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi +abbandonato) prevede inoltre la possibilità di associare le stesse ai singoli +file eseguibili, in modo da poter stabilire quali capacità possono essere +utilizzate quando viene messo in esecuzione uno specifico programma; ma il +supporto per questa funzionalità, chiamata \textit{file capabilities}, è stato +introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva essere +il programma stesso ad eseguire una riduzione esplicita delle sue capacità, +cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la presenza +di meccanismi alternativi per ottenere limitazioni delle capacità +dell'amministratore a livello di sistema operativo, come \textit{SELinux}. Con questo supporto e con le ulteriori modifiche introdotte con il kernel 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente @@ -6857,9 +6859,8 @@ opportuno dettagliare maggiormente. sez.~\ref{sec:file_perm_management}).\\ \const{CAP\_KILL} & Mandare segnali a qualunque processo (vedi sez.~\ref{sec:sig_kill_raise}).\\ - \const{CAP\_SETFCAP} & Impostare le - \textit{capabilities} di un file (dal kernel - 2.6.24).\\ + \const{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file (dal kernel + 2.6.24).\\ \const{CAP\_SETGID} & Manipolare i group ID dei processi, sia il principale che i supplementari, (vedi sez.~\ref{sec:proc_setgroups}) che quelli @@ -6915,9 +6916,11 @@ opportuno dettagliare maggiormente. \const{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\ \const{CAP\_MAC\_ADMIN} & Amministrare il \textit{Mandatory - Access Control} di Smack (dal kernel 2.6.25).\\ - \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory - Access Control} di Smack (dal kernel 2.6.25).\\ + Access Control} di \textit{Smack} (dal kernel + 2.6.25).\\ + \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory + Access Control} di \textit{Smack} (dal kernel + 2.6.25).\\ \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\ \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi sez.~\ref{sec:proc_priority}).\\ @@ -6950,10 +6953,6 @@ opportuno dettagliare maggiormente. \label{tab:proc_capabilities} \end{table} -% \footnotetext{vale a dire i permessi caratteristici del modello classico del -% controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)} -% \textit{Discrectionary Access Control} (da cui il nome DAC).} - Prima di dettagliare il significato della capacità più generiche, conviene però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è @@ -6967,17 +6966,16 @@ capacità è sempre stata assente (a meno di specifiche ricompilazioni del kernel) nel \textit{capabilities bounding set} usato di default, essa non è neanche mai stata realmente disponibile. -Con l'introduzione \itindex{file~capabilities} \textit{file capabilities} e -il cambiamento del significato del \textit{capabilities bounding set} la -possibilità di modificare le capacità di altri processi è stata completamente -rimossa, e \const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere -il suo significato originario, e cioè la capacità del processo di poter -inserire nel suo \textit{inheritable set} qualunque capacità presente nel -\textit{bounding set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} -consente ad un processo di eliminare una capacità dal proprio \textit{bounding - set} (con la conseguente impossibilità successiva di eseguire programmi con -quella capacità), o di impostare i \textit{securebits} delle -\textit{capabilities}. +Con l'introduzione \textit{file capabilities} e il cambiamento del significato +del \textit{capabilities bounding set} la possibilità di modificare le +capacità di altri processi è stata completamente rimossa, e +\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo +significato originario, e cioè la capacità del processo di poter inserire nel +suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding + set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un +processo di eliminare una capacità dal proprio \textit{bounding set} (con la +conseguente impossibilità successiva di eseguire programmi con quella +capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un @@ -7111,12 +7109,11 @@ utilizzare le interfacce di alto livello che vedremo più avanti. La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare, tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si -usano le \itindex{file~capabilities} \textit{file capabilities}, può essere -solo 0 o il \ids{PID} del processo chiamante, che sono equivalenti. Non -tratteremo, essendo comunque di uso irrilevante, il caso in cui, in mancanza -di tale supporto, la funzione può essere usata per modificare le -\textit{capabilities} di altri processi, per il quale si rimanda, se -interessati, alla lettura della pagina di manuale. +usano le \textit{file capabilities}, può essere solo 0 o il \ids{PID} del +processo chiamante, che sono equivalenti. Non tratteremo, essendo comunque di +uso irrilevante, il caso in cui, in mancanza di tale supporto, la funzione può +essere usata per modificare le \textit{capabilities} di altri processi, per il +quale si rimanda, se interessati, alla lettura della pagina di manuale. Il campo \var{version} deve essere impostato al valore della versione delle stesse usata dal kernel (quello indicato da una delle costanti @@ -7764,8 +7761,8 @@ a file al di fuori della sezione di albero in cui è stato \textsl{imprigionato}. Solo un processo con i privilegi di amministratore può usare questa -funzione,\footnote{più precisamente se possiede la \itindex{capabilities} - capacità \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in +funzione,\footnote{più precisamente se possiede la capacità + \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si tenga presente però che la funzione non cambia la directory di lavoro del processo, che potrebbe restare fuori dalla \textit{chroot jail}. diff --git a/process.tex b/process.tex index 5e2ab3d..4b18c30 100644 --- a/process.tex +++ b/process.tex @@ -1354,10 +1354,9 @@ standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce la memoria fisica disponibile nel sistema per gli altri processi, questo ha un evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9 -solo un processo dotato di privilegi amministrativi (la \itindex{capabilities} -\textit{capability} \const{CAP\_IPC\_LOCK}, vedi -sez.~\ref{sec:proc_capabilities}) aveva la capacità di bloccare una pagina di -memoria. +solo un processo dotato di privilegi amministrativi (la \textit{capability} +\const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la +capacità di bloccare una pagina di memoria. A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria memoria\footnote{la funzionalità è stata introdotta per non essere costretti a diff --git a/prochand.tex b/prochand.tex index d182a42..099e98b 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1603,9 +1603,9 @@ nell'esecuzione della funzione \func{exec}, queste sono: \begin{itemize*} \item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) pendenti vengono cancellate; -\item le \itindex{capabilities} \textit{capabilities} vengono modificate come +\item le \textit{capabilities} vengono modificate come illustrato in sez.~\ref{sec:proc_capabilities}; -\item tutti i \itindex{thread} \textit{thread} tranne il chiamante (vedi +\item tutti i \textit{thread} tranne il chiamante (vedi sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi; \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi @@ -1703,21 +1703,20 @@ problematiche connesse ad una gestione accorta dei privilegi. Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in realtà già esistono estensioni di questo modello base, che lo rendono più - flessibile e controllabile, come le \itindex{capabilities} - \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL - per i file (vedi sez.~\ref{sec:file_ACL}) o il - \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control} - di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con - SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una - infrastruttura di sicurezza, i \itindex{Linux~Security~Modules} - \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci - a livello del kernel per modularizzare tutti i possibili controlli di - accesso, cosa che ha permesso di realizzare diverse alternative a - \index{SELinux} SELinux.} di sicurezza di un sistema unix-like è fondato sui -concetti di utente e gruppo, e sulla separazione fra l'amministratore -(\textsl{root}, detto spesso anche \textit{superuser}) che non è sottoposto a -restrizioni, ed il resto degli utenti, per i quali invece vengono effettuati i -vari controlli di accesso. + flessibile e controllabile, come le \textit{capabilities} illustrate in + sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi + sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di + \textit{SELinux}; inoltre basandosi sul lavoro effettuato con + \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una + infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in + grado di fornire diversi agganci a livello del kernel per modularizzare + tutti i possibili controlli di accesso, cosa che ha permesso di realizzare + diverse alternative a \textit{SELinux}.} +di sicurezza di un sistema unix-like è fondato sui concetti di utente e +gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso +anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto +degli utenti, per i quali invece vengono effettuati i vari controlli di +accesso. Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID} @@ -2215,10 +2214,10 @@ chiamata con un vettore di dimensioni adeguate. Infine per impostare i gruppi supplementari di un processo ci sono due funzioni, che possono essere usate solo se si hanno i privilegi di -amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities} - \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione -di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, - ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per +amministratore.\footnote{e più precisamente se si ha la \textit{capability} + \macro{CAP\_SETGID}.} La prima delle due è la funzione di sistema +\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a + differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed il suo prototipo è: @@ -2505,13 +2504,12 @@ un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare il risultato nell'intervallo consentito. Valori positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della priorità, valori negativi comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12 -solo l'amministratore\footnote{o un processo con la \itindex{capabilities} - \textit{capability} \const{CAP\_SYS\_NICE}, vedi - sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi -di \param{inc} che permettono di aumentare la priorità di un processo, a -partire da questa versione è consentito anche agli utenti normali alzare -(entro certi limiti, che vedremo in sez.~\ref{sec:sys_resource_limit}) la -priorità dei propri processi. +solo l'amministratore\footnote{o un processo con la \textit{capability} + \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può +specificare valori negativi di \param{inc} che permettono di aumentare la +priorità di un processo, a partire da questa versione è consentito anche agli +utenti normali alzare (entro certi limiti, che vedremo in +sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi. Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non @@ -2634,18 +2632,18 @@ anche in questo caso per rilevare un errore occorre sempre porre a zero \textit{nice} valido. Si tenga presente che solo l'amministratore\footnote{o più precisamente un - processo con la \itindex{capabilities} \textit{capability} - \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la -possibilità di modificare arbitrariamente le priorità di qualunque -processo. Un utente normale infatti può modificare solo la priorità dei suoi -processi ed in genere soltanto diminuirla. Fino alla versione di kernel -2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i -sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello -effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo -a quello) del processo di cui si intendeva cambiare la priorità. A partire -dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi -derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere -anche con l'\ids{UID} effettivo. + processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi + sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare +arbitrariamente le priorità di qualunque processo. Un utente normale infatti +può modificare solo la priorità dei suoi processi ed in genere soltanto +diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le +specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV +veniva richiesto che l'\ids{UID} reale o quello effettivo del processo +chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo +di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è +stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS, +Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID} +effettivo. Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti ordinari poter aumentare la priorità dei propri processi specificando un @@ -2885,7 +2883,7 @@ sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo nel caso che esso sia stato interrotto da un processo a priorità più alta. Solo un processo con i privilegi di amministratore\footnote{più precisamente - con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi + con la capacità \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità assolute diverse da zero o politiche \const{SCHED\_FIFO} e \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di @@ -3623,26 +3621,24 @@ momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.} \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} \item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle - \itindex{capabilities} \textit{capabilities} (vedi - sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità - specificata nell'argomento \param{arg2} (con una delle costanti di - tab.~\ref{tab:proc_capabilities}) è presente nel \textit{capabilities - bounding set} del processo e zero altrimenti, se \param{arg2} non è un - valore valido si avrà un errore di \errval{EINVAL}. Introdotta a partire - dal kernel 2.6.25. + \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione + ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una + delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel + \textit{capabilities bounding set} del processo e zero altrimenti, + se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}. + Introdotta a partire dal kernel 2.6.25. \item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle - \itindex{capabilities} \textit{capabilities} (vedi - sez.~\ref{sec:proc_capabilities}) dal processo e da tutti i suoi - discendenti. La funzione cancella la capacità specificata + \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e + da tutti i suoi discendenti. La funzione cancella la capacità specificata nell'argomento \param{arg2} con una delle costanti di - tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} - \itindex{capabilities~bounding~set} del processo. L'operazione richiede i - privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), altrimenti - la chiamata fallirà con un errore di \errcode{EPERM}; se il valore - di \param{arg2} non è valido o se il supporto per le \textit{file - capabilities} non è stato compilato nel kernel la chiamata fallirà con un - errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25. + tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del + processo. L'operazione richiede i privilegi di amministratore (la capacità + \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di + \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto + per le \textit{file capabilities} non è stato compilato nel kernel la + chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal + kernel 2.6.25. \item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la terminazione di un processo a causa di un segnale per il quale è prevista la @@ -3724,8 +3720,8 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. a partire dal kernel 2.4.21, solo su PowerPC. \item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali - \itindex{capabilities} \textit{capabilities} vengono cancellate quando si - esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda + \textit{capabilities} vengono cancellate quando si esegue un cambiamento di + \ids{UID} del processo (per i dettagli si veda sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default) per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano @@ -3736,9 +3732,8 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. dal kernel 2.2.18. \item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione - il valore del flag di controllo delle \itindex{capabilities} - \textit{capabilities} impostato con \const{PR\_SET\_KEEPCAPS}. Introdotta a - partire dal kernel 2.2.18. + il valore del flag di controllo delle \textit{capabilities} impostato con + \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18. \item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il @@ -3803,9 +3798,9 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione - richiede i privilegi di amministratore (la \itindex{capabilities} capacità - \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di - \errval{EPERM}. Introdotta a partire dal kernel 2.6.26. + richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), + altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a + partire dal kernel 2.6.26. \item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della funzione l'impostazione corrente per i \itindex{securebits}