X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=b1f8e7615086434a0acb31c9ba9073c20c879594;hp=04a8d1dfdd20dbf340e55df20af1504e95c3fd93;hb=b81723c64c1d63b89cd3cec12f2fcccc4a756967;hpb=6271cd1b0cc4d403753d1f48d3d562b16db7e613 diff --git a/filedir.tex b/filedir.tex index 04a8d1d..b1f8e76 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,6 +1,6 @@ %% filedir.tex %% -%% Copyright (C) 2000-2009 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2010 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", @@ -613,12 +613,14 @@ file nella directory. \subsection{La creazione di file speciali} \label{sec:file_mknod} +\index{file!di~dispositivo|(} + Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure -degli altri tipi di file speciali, come i \index{file!di~dispositivo} file di -dispositivo, le fifo ed i socket (questi ultimi sono un caso a parte, essendo -associati anche alla comunicazione via rete, per cui ci saranno trattati in -dettaglio a partire da cap.~\ref{cha:socket_intro}). +degli altri tipi di file speciali, come i file di dispositivo, le fifo ed i +socket (questi ultimi sono un caso a parte, essendo associati anche alla +comunicazione via rete, per cui ci saranno trattati in dettaglio a partire da +cap.~\ref{cha:socket_intro}). La manipolazione delle caratteristiche di questi diversi tipi di file e la loro cancellazione può essere effettuata con le stesse funzioni che operano @@ -672,15 +674,15 @@ o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovr 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 -\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. +\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. I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno al proprietario e al gruppo del processo che li ha creati, a meno che non si @@ -747,6 +749,8 @@ relativo identificativo con la macro \macro{makedev}: \textit{major number} e \itindex{minor~number} \textit{minor number}. \end{functions} +\index{file!di~dispositivo|)} + Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica per creare una fifo (tratteremo le fifo in in sez.~\ref{sec:ipc_named_pipe}); la funzione è \funcd{mkfifo} ed il suo prototipo è: @@ -1676,9 +1680,10 @@ dimensione inferiore sarebbe inefficiente. Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è detto che corrisponda all'occupazione dello spazio su disco per via della -possibile esistenza dei cosiddetti \textit{holes} (letteralmente -\textsl{buchi}) che si formano tutte le volte che si va a scrivere su un file -dopo aver eseguito una \func{lseek} (vedi sez.~\ref{sec:file_lseek}) oltre la +possibile esistenza dei cosiddetti \index{file!\textit{hole}} \textit{holes} +(letteralmente \textsl{buchi}) che si formano tutte le volte che si va a +scrivere su un \itindex{sparse~file} file dopo aver eseguito una \func{lseek} +(tratteremo in dettaglio l'argomento in sez.~\ref{sec:file_lseek}) oltre la sua fine. In questo caso si avranno risultati differenti a seconda del modo in cui si @@ -1728,9 +1733,9 @@ dimensione si possono usare le due funzioni \funcd{truncate} e Se il file è più lungo della lunghezza specificata i dati in eccesso saranno perduti; il comportamento in caso di lunghezza inferiore non è specificato e dipende dall'implementazione: il file può essere lasciato invariato o esteso -fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con -zeri (e in genere si ha la creazione di un \textit{hole} nel file). - +fino alla lunghezza scelta; nel caso di Linux viene esteso con la creazione di +un \index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e +ad una lettura si otterranno degli zeri. \subsection{I tempi dei file} \label{sec:file_file_times} @@ -1961,9 +1966,9 @@ volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla chiamata di \func{utime}). Questo serve anche come misura di sicurezza per evitare che si possa modificare un file nascondendo completamente le proprie tracce. In realtà la cosa resta possibile, se si è in grado di accedere al -file di dispositivo, scrivendo direttamente sul disco senza passare attraverso -il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da -realizzare. +\index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul +disco senza passare attraverso il filesystem, ma ovviamente in questo modo la +cosa è molto più complicata da realizzare. A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai @@ -2642,7 +2647,7 @@ Per alcuni filesystem\footnote{i filesystem pi 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 capability + precisione un processo che non dispone della \itindex{capabilities} capacità \const{CAP\_FSETID}.} 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. @@ -2770,7 +2775,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono: \end{functions} Con Linux solo l'amministratore\footnote{o in generale un processo con la - \itindex{capabilities} capability \const{CAP\_CHOWN}, vedi + \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 @@ -2801,10 +2806,10 @@ sez.~\ref{sec:file_mand_locking}). \label{sec:file_riepilogo} Avendo affrontato in maniera separata il comportamento delle varie funzioni -che operano su di essi ed avendo trattato il significato dei singoli bit dei -permessi sui file in sezioni diverse, vale la pena di fare un riepilogo in cui -si riassumano le caratteristiche di ciascuno di essi, in modo da poter fornire -un quadro d'insieme. +che operano sui permessi dei file ed avendo trattato in sezioni diverse il +significato dei singoli bit dei permessi, vale la pena di fare un riepilogo in +cui si riassumano le caratteristiche di ciascuno di essi, in modo da poter +fornire un quadro d'insieme. \begin{table}[!htb] \centering @@ -2870,17 +2875,22 @@ un quadro d'insieme. \end{table} Nella parte superiore di tab.~\ref{tab:file_fileperm_bits} si è riassunto il -significato dei vari bit dei permessi per un file; per quanto riguarda -l'applicazione dei permessi per proprietario, gruppo ed altri si ricordi -quanto illustrato in sez.~\ref{sec:file_perm_overview}. Per compattezza, -nella tabella si sono specificati i bit di \itindex{suid~bit} \textit{suid}, -\itindex{sgid~bit} \textit{sgid} e \textit{sticky} \itindex{sticky~bit} con la -notazione illustrata anche in fig.~\ref{fig:file_perm_bit}. Nella parte -inferiore si sono invece riassunti i significati dei vari bit dei permessi per -una directory; anche in questo caso si e` riapplicato ai bit di -\itindex{suid~bit} \textit{suid}, \itindex{sgid~bit} \textit{sgid} e -\textit{sticky} \itindex{sticky~bit} con la notazione illustrata in -fig.~\ref{fig:file_perm_bit}. +significato dei vari bit dei permessi per un file ordinario; per quanto +riguarda l'applicazione dei permessi per proprietario, gruppo ed altri si +ricordi quanto illustrato in sez.~\ref{sec:file_perm_overview}. Per +compattezza, nella tabella si sono specificati i bit di \itindex{suid~bit} +\textit{suid}, \itindex{sgid~bit} \textit{sgid} e \textit{sticky} +\itindex{sticky~bit} con la notazione illustrata anche in +fig.~\ref{fig:file_perm_bit}. Nella parte inferiore si sono invece riassunti +i significati dei vari bit dei permessi per una directory; anche in questo +caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid}, +\itindex{sgid~bit} \textit{sgid} e \textit{sticky} \itindex{sticky~bit} la +notazione illustrata in fig.~\ref{fig:file_perm_bit}. + +Si ricordi infine che i permessi non hanno alcun significato per i link +simbolici, mentre per i \index{file!di~dispositivo} file di dispositivo hanno +senso soltanto i permessi di lettura e scrittura, che si riflettono sulla +possibilità di compiere dette operazioni sul dispositivo stesso. Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del bit in questione non è influente rispetto a quanto indicato nella riga della @@ -2935,29 +2945,107 @@ molto pi situazione di \textsl{tutto o nulla}. Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione - di Linux si rifà ad una bozza per quello che dovrebbe divenire lo standard - POSIX.1e, che prevede questa funzionalità.} prevederebbe anche la -possibilità di associare le stesse \textit{capabilities} anche ai singoli file -eseguibili,\footnote{una descrizione sommaria di questa funzionalità è - riportata nella pagina di manuale che descrive l'implementazione delle - \textit{capabilities} con Linux (accessibile con \texttt{man capabilities}), - ma non essendo implementata non ne tratteremo qui.} in modo da poter -stabilire quali capacità possono essere utilizzate quando viene messo in -esecuzione uno specifico programma; attualmente però questa funzionalità non è -implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; - benché l'infrastruttura per crearla sia presente (vedi anche - sez.~\ref{sec:file_xattr}) finora non è disponibile nessuna realizzazione - delle specifiche POSIX.1e, esistono però dei patch di sicurezza del kernel, - come LIDS (vedi \href{http://www.lids.org}{\textsf{http://www.lids.org/})} - che realizzano qualcosa di simile.} + si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e, + ormai 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à è 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 come +\index{SELinux} SELinux. + +Per gestire questo meccanismo ciascun processo porta con sé tre distinti +insiemi di \textit{capabilities}, che vengono denominati rispettivamente +\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi +vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel + li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid}, + all'interno della \struct{task\_struct} di ciascun processo (vedi + fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective}, + \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo + \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit, + il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui +ciascun bit corrisponde ad una capacità diversa. + +L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile +per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui +sono mantenuti i diversi insiemi di identificatori di +sez.~\ref{sec:proc_setuid}; il loro significato è il seguente: +\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}} +\item[\textit{effective}] l'insieme delle \textit{capabilities} + ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal + kernel quando deve eseguire il controllo di accesso per le varie operazioni + compiute dal processo. +\item[\textit{permitted}] l'insieme delle \textit{capabilities} + ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo + \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una + capacità da questo insieme non potrà più riassumerla (almeno che non esegua + un programma che è \acr{suid} di root). +\item[\textit{inherited}] l'insieme delle \textit{capabilities} + ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo + programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione + del caso che questo sia \acr{suid} di root). +\label{sec:capabilities_set} +\end{basedescript} + +Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel +mantiene un insieme generale valido per tutto il sistema, chiamato +\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni +volta che un programma viene posto in esecuzione con \func{exec} il contenuto +degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con +un \textsl{AND} binario del contenuto corrente del \textit{capabilities + bounding set}, così che il nuovo processo potrà disporre soltanto delle +capacità in esso elencate. + +Il \textit{capabilities bounding set} è un parametro di sistema, accessibile +attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per +questa sua caratteristica consente di impostare un limite generale alle +capacità che possono essere accordate ai vari processi. Questo valore può +essere impostato ad un valore arbitrario esclusivamente dal primo processo +eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo +eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se +eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit +già presenti dell'insieme: questo significa che una volta rimossa una +\textit{capability} dal \textit{capabilities bounding set} essa non sarà più +disponibile, neanche per l'amministratore, a meno di un riavvio. + +Quando un programma viene messo in esecuzione\footnote{cioè quando viene + eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una + \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita +(nel senso che assume negli insiemi \textit{effective} e \textit{permitted}) +le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che +non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata +eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma +ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities + bounding set}. In questo modo si può far si che ad un processo eseguito in +un secondo tempo possano essere trasmesse solo un insieme limitato di +capacità, impedendogli di recuperare quelle assenti nell'insieme +\textit{inherited}. Si tenga presente invece che attraverso una \func{fork} +vengono mantenute le stesse capacità del processo padre. + % TODO verificare per process capability bounding set, vedi: % http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e -% TODO capire cosa cambia con i patch del 2.6.26, vedi +% TODO capire cosa cambia con i patch vari, vedi % http://lwn.net/Articles/280279/ - -\begin{table}[!h!btp] +% http://lwn.net/Articles/256519/ +% http://lwn.net/Articles/211883/ + + +Un elenco delle delle \textit{capabilities} disponibili su Linux, con una +breve descrizione ed il nome delle costanti che le identificano, è riportato +in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa + tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man + capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è + aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima +riporta le \textit{capabilities} previste anche nella bozza dello standard +POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla +tabella alcune \textit{capabilities} attengono a singole funzionalità e sono +molto specializzate, mentre altre hanno un campo di applicazione molto vasto, +che è opportuno dettagliare maggiormente. + +\begin{table}[!h!bt] \centering \footnotesize \begin{tabular}{|l|p{12cm}|} @@ -2968,42 +3056,27 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; % % POSIX-draft defined capabilities. % + \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di + auditing del kernel (dal kernel 2.6.11).\\ + \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il + controllo dell'auditing (dal kernel 2.6.11).\\ + % TODO verificare questa roba dell'auditing \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo proprietario di un file (vedi sez.~\ref{sec:file_ownership_management}).\\ \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei permessi di lettura, scrittura ed esecuzione dei - file, (vedi sez.~\ref{sec:file_access_control}) - caratteristici del modello classico del - controllo di accesso chiamato - \itindex{Discrectionary~Access~Control~(DAC)} - \textit{Discrectionary Access Control} (da cui - il nome DAC).\\ + file,\footnotemark (vedi + sez.~\ref{sec:file_access_control}).\\ \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei - permessi di lettura, scrittura ed esecuzione per + permessi di lettura ed esecuzione per le directory (vedi sez.~\ref{sec:file_access_control}).\\ - \const{CAP\_FOWNER} & La capacità di evitare il controllo che - l'user-ID effettivo del processo (o meglio il - \textit{filesystem user-ID}, vedi - sez.~\ref{sec:proc_setuid}) coincida con - quello del proprietario di un file per tutte + \const{CAP\_FOWNER} & La capacità di evitare il controllo della + proprietà di un file per tutte le operazioni privilegiate non coperte dalle precedenti \const{CAP\_DAC\_OVERRIDE} e - \const{CAP\_DAC\_READ\_SEARCH}. Queste - comprendono i cambiamenti dei permessi e dei - tempi del file (vedi - sez.~\ref{sec:file_perm_management} e - sez.~\ref{sec:file_file_times}), le impostazioni - degli attributi estesi (con il comando - \cmd{chattr}) e delle ACL, poter ignorare lo - \itindex{sticky~bit} \textit{sticky bit} nella - cancellazione dei file (vedi - sez.~\ref{sec:file_special_perm}), la possibilità - di impostare il flag di \const{O\_NOATIME} con - \func{open} e \func{fcntl} (vedi - sez.~\ref{sec:file_open} e - sez.~\ref{sec:file_fcntl}).\\ + \const{CAP\_DAC\_READ\_SEARCH}.\\ \const{CAP\_FSETID} & La capacità di evitare la cancellazione automatica dei bit \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid} quando un file @@ -3013,49 +3086,25 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; quando questo è relativo ad un gruppo cui non si appartiene (vedi sez.~\ref{sec:file_perm_management}).\\ + \const{CAP\_SETFCAP} & La capacità di impostare le + \textit{capabilities} di un file (dal kernel + 2.6.24).\\ \const{CAP\_KILL} & La capacità di mandare segnali a qualunque processo (vedi sez.~\ref{sec:sig_kill_raise}).\\ \const{CAP\_SETGID} & La capacità di manipolare i group ID dei processi, sia il principale che i supplementari, - (vedi sez.~\ref{sec:proc_setgroups} che quelli + (vedi sez.~\ref{sec:proc_setgroups}) che quelli trasmessi tramite i socket \textit{unix domain} (vedi sez.~\ref{sec:unix_socket}).\\ \const{CAP\_SETUID} & La capacità di manipolare gli user ID del - processo (con \func{setuid}, \func{setreuid}, - \func{setresuid}, \func{setfsuid}) e di - trasmettere un valore arbitrario - dell'\textsl{uid} nel passaggio delle - credenziali coi socket \textit{unix domain} (vedi - sez.~\ref{sec:unix_socket}).\\ + processo (vedi sez.~\ref{sec:proc_setuid}) e di + trasmettere un user ID arbitrario nel passaggio + delle credenziali coi socket \textit{unix + domain} (vedi sez.~\ref{sec:unix_socket}).\\ % % Linux specific capabilities % \hline - \const{CAP\_SETPCAP} & La capacità di impostare o rimuovere una capacità - (limitatamente a quelle che il processo - chiamante ha nel suo insieme di capacità - permesse) da qualunque processo.\\ -% TODO cambiata nel 2.4.24 rc1 ? - \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare gli attributi - \textit{immutable} e \itindex{append~mode} - \textit{append only} per i file su un - filesystem che supporta questi - attributi estesi.\\ - \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porre in ascolto server - su porte riservate (vedi - sez.~\ref{sec:TCP_func_bind}).\\ - \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in - \itindex{broadcast} \textit{broadcast} e - \itindex{multicast} \textit{multicast}.\\ - \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni - privilegiate sulla rete (impostare le opzioni - privilegiate dei socket, abilitare il - \itindex{multicast} \textit{multicasting}, - impostare interfacce di rete e - tabella di instradamento).\\ - \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e - \texttt{PACKET} (quelli che permettono di creare - pacchetti nei protocolli di basso livello).\\ \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory locking} \itindex{memory~locking} con le funzioni \func{mlock}, \func{mlockall}, @@ -3066,53 +3115,64 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; per le operazioni sugli oggetti di intercomunicazione fra processi (vedi sez.~\ref{sec:ipc_sysv}).\\ - \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del - kernel. \\ - \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte - di I/O con \func{ioperm} e \func{iopl} (vedi - sez.~\ref{sec:file_io_port}).\\ + \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease} + \index{file!lease} (vedi + sez.~\ref{sec:file_asyncronous_lease}) + pur non essendo proprietari del file (dal kernel + 2.4).\\ + \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli + attributi \textit{immutable} e + \itindex{append~mode} \textit{append only} (se + supportati).\\ + \const{CAP\_MKNOD} & La capacità di creare + \index{file!di~dispositivo} file di dispositivo + con \func{mknod} (vedi + sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\ + \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni + privilegiate sulla rete.\\ + \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto + su porte riservate (vedi + sez.~\ref{sec:TCP_func_bind}).\\ + \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in + \itindex{broadcast} \textit{broadcast} e + \itindex{multicast} \textit{multicast}.\\ + \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e + \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\ + \const{CAP\_SETPCAP} & La capacità di impostare o rimuovere una + capacità.\\ + % TODO cambiata nel 2.4.24 rc1 ? + \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti + amministrativi. \\ + \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del + sistema.\\ +% TODO trattare reboot e kexec \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\ - \const{CAP\_SYS\_PTRACE}& Consente di tracciare qualunque processo con - \func{ptrace} (vedi - sez.~\ref{sec:xxx_ptrace}).\\ + \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal + kernel 2.6.25).\\ + \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal + kernel 2.6.25).\\ + \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del + kernel. \\ + \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei + processi. \\ \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di \textit{accounting} dei processi (vedi sez.~\ref{sec:sys_bsd_accounting}).\\ - \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti - amministrativi (come impostare le quote, - attivare e disattivare la swap, montare, - rimontare e smontare filesystem, ecc.). \\ - \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del - sistema.\\ -% TODO trattare reboot e kexec - \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei - processi (vedi sez.~\ref{sec:proc_priority}). \\ + \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con + \func{ptrace} (vedi + sez.~\ref{sec:xxx_ptrace}).\\ + \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte + di I/O con \func{ioperm} e \func{iopl} (vedi + sez.~\ref{sec:file_io_port}).\\ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle - risorse, aumentare le quote disco, usare lo - spazio disco riservato all'amministratore.\\ + risorse.\\ \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema (vedi sez.~\ref{sec:sys_time}).\\ \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup} della console, con la funzione \func{vhangup}.\\ - \const{CAP\_MKNOD} & La capacità di creare file di dispositivo con la - funzione \func{mknod} (vedi - sez.~\ref{sec:file_mknod}).\footnotemark\\ - \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease} - \index{file!lease} su di un file (vedi - sez.~\ref{sec:file_asyncronous_lease}) - indipendentemente dalla proprietà dello - stesso.\footnotemark\\ - \const{CAP\_SETFCAP} & La capacità di impostare le - \textit{capabilities} di un file (non - supportata).\\ - \const{CAP\_AUDIT\_WRITE}&consente la scrittura di dati nel giornale di - auditing del kernel.\\ - \const{CAP\_AUDIT\_CONTROL}& consente di abilitare e disabilitare il - controllo dell'auditing.\footnotemark\\ -% TODO verificare questa roba dell'auditing \hline \end{tabular} \caption{Le costanti che identificano le \textit{capabilities} presenti nel @@ -3120,90 +3180,67 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; \label{tab:proc_capabilities} \end{table} -\footnotetext[21]{questa capacità è presente soltanto a partire dai kernel - della serie 2.4.x.} - -\footnotetext[22]{questa capacità è presente soltanto a partire dai kernel della - serie 2.4.x.} - -\footnotetext{queste ultime due capacità sono presenti soltanto a partire dai - kernel della serie 2.6.11.} - -Per gestire questo nuovo meccanismo ciascun processo porta con sé tre distinti -insiemi di \textit{capabilities}, che vengono denominati rispettivamente -\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi -vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel - li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid}, - all'interno della \struct{task\_struct} di ciascun processo (vedi - fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective}, - \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo - \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit, - il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui -ciascun bit corrisponde ad una capacità diversa; se ne è riportato -l'elenco,\footnote{si tenga presente che l'elenco delle \textit{capabilities} - presentato questa tabella, ripreso dalla relativa pagina di manuale - (accessibile con \texttt{man capabilities}) e dalle definizioni in - \texttt{sys/capabilities.h}, è quello aggiornato al kernel 2.6.6.} con una -breve descrizione, ed il nome delle costanti che identificano i singoli bit, -in tab.~\ref{tab:proc_capabilities}; la tabella è divisa in due parti, la -prima riporta le \textit{capabilities} previste nella bozza dello standard -POSIX1.e, la seconda quelle specifiche di Linux. - -L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile -per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui -sono mantenuti i diversi insiemi di identificatori di -sez.~\ref{sec:proc_setuid}; il loro significato è il seguente: -\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}} -\item[\textit{effective}] l'insieme delle \textit{capabilities} - ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal - kernel quando deve eseguire il controllo di accesso per le varie operazioni - compiute dal processo. -\item[\textit{permitted}] l'insieme delle \textit{capabilities} - ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo - \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una - capacità da questo insieme non potrà più riassumerla (almeno che non esegua - un programma che è \acr{suid} di root). -\item[\textit{inherited}] l'insieme delle \textit{capabilities} - ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo - programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione - del caso che questo sia \acr{suid} di root). -\label{sec:capabilities_set} -\end{basedescript} - -Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel -mantiene un insieme generale valido per tutto il sistema, chiamato -\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni -volta che un programma viene posto in esecuzione con \func{exec} il contenuto -degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con -un \textsl{AND} binario del contenuto corrente del \textit{capabilities - bounding set}, così che il nuovo processo potrà disporre soltanto delle -capacità in esso elencate. +\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).} + +La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che +rimuove le restrizioni poste ad un processo che non ha la proprietà di un file +in un vasto campo di operazioni;\footnote{vale a dire la richiesta che + l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID}, + vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} +queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi +sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le +impostazioni degli attributi estesi e delle ACL (vedi +sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo +\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi +sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di +\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi +sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni. + +Una seconda capacità che copre diverse operazioni, in questo caso riguardanti +la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni +privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare +il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle +interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la +tabella di instradamento. + +Una terza \textit{capability} con vasto campo di applicazione è +\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative, +come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e +disattivare la swap, montare, rimontare e smontare filesystem (vedi +sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli +oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli +attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi +sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella +trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}), +assegnare classi privilegiate per lo scheduling dell'I/O (vedi +sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo +di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.} +effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi +sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi +sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare}, +(vedi sez.~\ref{sec:process_clone}). + +Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di +aumentare le priorità di esecuzione dei processi, come la diminuzione del +valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle +priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o +l'impostazione delle affinità di processore (vedi +sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità +anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA, +alla memoria, essa viene a coprire anche la possibilità di assegnare priorità +arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle +politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA. + +Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla +possibilità di superare i limiti imposti sulle risorse di sistema, come usare +lo spazio disco riservato all'amministratore sui filesystem che lo supportano, +usare la funzione \func{ioctl} per controllare il \textit{journaling} sul +filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle +risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei +messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}). -Il \textit{capabilities bounding set} è un parametro di sistema, accessibile -attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per -questa sua caratteristica consente di impostare un limite generale alle -capacità che possono essere accordate ai vari processi. Questo valore può -essere impostato ad un valore arbitrario esclusivamente dal primo processo -eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo -eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se -eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit -già presenti dell'insieme: questo significa che una volta rimossa una -\textit{capability} dal \textit{capabilities bounding set} essa non sarà più -disponibile, neanche per l'amministratore, a meno di un riavvio. - -Quando un programma viene messo in esecuzione\footnote{cioè quando viene - eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una - \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita -(nel senso che assume negli insiemi \textit{effective} e \textit{permitted}) -le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che -non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata -eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma -ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities - bounding set}. In questo modo si può far si che ad un processo eseguito in -un secondo tempo possano essere trasmesse solo un insieme limitato di -capacità, impedendogli di recuperare quelle assenti nell'insieme -\textit{inherited}. Si tenga presente invece che attraverso una \func{fork} -vengono mantenute le stesse capacità del processo padre. Per la gestione delle \textit{capabilities} il kernel mette a disposizione due funzioni che permettono rispettivamente di leggere ed impostare i valori dei @@ -3713,7 +3750,8 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. \itindex{Linux~Security~Modules} \textit{Linux Security Modules}), per le realizzazione di meccanismi evoluti di controllo di accesso come \index{SELinux} - SELinux.\\ + SELinux o le \textit{capabilities} dei file di + sez.~\ref{sec:proc_capabilities}.\\ \const{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 (vedi @@ -3784,30 +3822,32 @@ casi: directory ordinarie, se valesse in generale infatti si avrebbe un serio problema di sicurezza dato che esistono diversi oggetti sul filesystem per i quali è normale avere avere il permesso di scrittura consentito a tutti gli - utenti, come i link simbolici, o alcuni file di dispositivo come - \texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended - user attributes} un utente qualunque potrebbe inserirvi dati a - piacere.\footnote{la cosa è stata notata su XFS, dove questo comportamento - permetteva, non essendovi limiti sullo spazio occupabile dagli - \textit{Extended Attributes}, di bloccare il sistema riempiendo il disco.} + utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di + dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli + \textit{extended user attributes} un utente qualunque potrebbe inserirvi + dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo + comportamento permetteva, non essendovi limiti sullo spazio occupabile + dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il + disco.} La semantica del controllo di accesso indicata inoltre non avrebbe alcun senso al di fuori di file e directory: i permessi di lettura e scrittura per - un file di dispositivo attengono alle capacità di accesso al dispositivo - sottostante,\footnote{motivo per cui si può formattare un disco anche se - \texttt{/dev} è su un filesystem in sola lettura.} mentre per i link - simbolici questi vengono semplicemente ignorati: in nessuno dei due casi - hanno a che fare con il contenuto del file, e nella discussione relativa - all'uso degli \textit{extended user attributes} nessuno è mai stato capace - di indicare una qualche forma sensata di utilizzo degli stessi per link - simbolici o file di dispositivo, e neanche per le fifo o i socket. Per - questo motivo essi sono stati completamente disabilitati per tutto ciò che - non sia un file regolare o una directory.\footnote{si può verificare la - semantica adottata consultando il file \texttt{fs/xattr.c} dei sorgenti - del kernel.} Inoltre per le directory è stata introdotta una ulteriore - restrizione, dovuta di nuovo alla presenza ordinaria di permessi di - scrittura completi su directory come \texttt{/tmp}. Per questo motivo, per - evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit} + un \index{file!di~dispositivo} file di dispositivo attengono alle capacità + di accesso al dispositivo sottostante,\footnote{motivo per cui si può + formattare un disco anche se \texttt{/dev} è su un filesystem in sola + lettura.} mentre per i link simbolici questi vengono semplicemente + ignorati: in nessuno dei due casi hanno a che fare con il contenuto del + file, e nella discussione relativa all'uso degli \textit{extended user + attributes} nessuno è mai stato capace di indicare una qualche forma + sensata di utilizzo degli stessi per link simbolici o + \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i + socket. Per questo motivo essi sono stati completamente disabilitati per + tutto ciò che non sia un file regolare o una directory.\footnote{si può + verificare la semantica adottata consultando il file \texttt{fs/xattr.c} + dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una + ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi + di scrittura completi su directory come \texttt{/tmp}. Per questo motivo, + 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 capability \index{capabilities} @@ -4017,12 +4057,14 @@ file descriptor, da specificare con il loro primo argomento. Anche in questo caso l'argomento \param{name} deve essere specificato con le modalità già illustrate in precedenza per le altre funzioni relative agli attributi estesi. - \itindend{Extended~Attributes} + \subsection{Le \textit{Access Control List}} \label{sec:file_ACL} +% la documentazione di sistema è nei pacchetti libacl1-dev e acl +% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/ \itindbeg{Access~Control~List} @@ -4795,9 +4837,6 @@ ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con \itindend{Access~Control~List} -% la documentazione di sistema è nei pacchetti libacl1-dev e acl -% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/ - \subsection{La funzione \func{chroot}} @@ -4856,7 +4895,7 @@ chiamate nel processo sar accedere alla parte di albero sovrastante. Si ha così quella che viene chiamata una \textit{chroot jail}, in quanto il processo non può più accedere a file al di fuori della sezione di albero in cui è stato -\textsl{imprigionato}. +\textsl{imprigionato}. Solo un processo con i privilegi di amministratore può usare questa funzione, e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata @@ -4890,7 +4929,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd -% LocalWords: int const char oldpath newpath errno EXDEV EPERM st +% LocalWords: int const char oldpath newpath errno EXDEV EPERM st Smack SysV % LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls % LocalWords: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap % LocalWords: POSIX socket fifo sticky root system call count crash nell' init @@ -4938,7 +4977,8 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND % LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef % LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm -% LocalWords: fffffeff CapEff getcap +% LocalWords: fffffeff CapEff getcap dell'IPC scheduling dell'I lookup dcookie +% LocalWords: NEWNS unshare nice NUMA ioctl journaling %%% Local Variables: %%% mode: latex