X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=df4576e1238d4687733bae7efbb2b5466a1414d2;hp=dc97d8b8548e5da9798d39c0f38c4796c32f9ac3;hb=6760429dc70f868716393c4413c5450b0649869b;hpb=67794e5214c13e46667b290dfd9f3014261a41d7 diff --git a/filedir.tex b/filedir.tex index dc97d8b..df4576e 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,6 +1,6 @@ %% filedir.tex %% -%% Copyright (C) 2000-2014 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -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 @@ -2025,9 +2025,9 @@ directory. Si tenga presente che comunque la funzione opera associando il \textit{directory stream} ad un opportuno file descriptor sottostante, sul quale vengono compiute le operazioni. Questo viene sempre aperto impostando il -flag di \itindex{close-on-exec} \textit{close-on-exec} (si ricordi quanto -detto in sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso -di esecuzione di un altro programma. +flag di \textit{close-on-exec} (si ricordi quanto detto in +sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di +esecuzione di un altro programma. Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato ad un \textit{directory stream} si può usare la funzione @@ -2098,9 +2098,8 @@ funzioni che operano sul \textit{directory stream} e non dovrà essere più utilizzato all'interno del proprio programma. In particolare dovrà essere chiuso attraverso il \textit{directory stream} con \func{closedir} e non direttamente. Si tenga presente inoltre che \func{fdopendir} non modifica lo -stato di un eventuale flag di \itindex{close-on-exec} \textit{close-on-exec}, -che pertanto dovrà essere impostato esplicitamente in fase di apertura del -file descriptor. +stato di un eventuale flag di \textit{close-on-exec}, che pertanto dovrà +essere impostato esplicitamente in fase di apertura del file descriptor. Una volta che si sia aperto un \textit{directory stream} la lettura del contenuto della directory viene effettuata attraverso la funzione @@ -2715,16 +2714,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 +3641,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 +3872,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 +4106,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 +4453,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 +4592,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 +4750,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 +4811,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 +4838,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 +4910,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 +5177,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 +5295,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 +6149,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 +6403,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 +6416,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 +6442,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 +6858,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 @@ -6891,8 +6891,7 @@ opportuno dettagliare maggiormente. pur non essendo proprietari del file (dal kernel 2.4).\\ \const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi - \textit{immutable} e \itindex{append~mode} - \textit{append-only} (vedi + \textit{immutable} e \textit{append-only} (vedi sez.~\ref{sec:file_perm_overview}) se supportati.\\ \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di @@ -6915,9 +6914,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 +6951,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 +6964,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 +7107,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 +7759,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}.