From d79bcd4b47524a895d04e30bd6b641cacfa0eecf Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sat, 27 Jun 2009 16:35:10 +0000 Subject: [PATCH] Inizio risistemazione delle capabilities --- filedir.tex | 150 +++++++++++++++++++++++++++------------------------- 1 file changed, 79 insertions(+), 71 deletions(-) diff --git a/filedir.tex b/filedir.tex index 04a8d1d..98e87ca 100644 --- a/filedir.tex +++ b/filedir.tex @@ -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 @@ -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 è: @@ -1961,9 +1965,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 @@ -2801,10 +2805,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 +2874,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 +possibilita 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 @@ -2936,26 +2945,21 @@ 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.} + POSIX.1e, che prevede questa funzionalità.} prevedeva anche la possibilità +di associare le stesse \textit{capabilities} anche 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. + + % 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/ +% http://lwn.net/Articles/256519/ +% http://lwn.net/Articles/211883/ \begin{table}[!h!btp] \centering @@ -2968,6 +2972,10 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; % % POSIX-draft defined capabilities. % + \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\\ \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo proprietario di un file (vedi sez.~\ref{sec:file_ownership_management}).\\ @@ -3097,8 +3105,9 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; \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 + \const{CAP\_MKNOD} & La capacità di creare + \index{file!di~dispositivo} 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 @@ -3108,10 +3117,6 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23; \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} @@ -3120,15 +3125,15 @@ 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 +\footnotetext[21]{queste prime due capacità sono presenti soltanto a partire dai + kernel della serie 2.6.11.} + +\footnotetext[22]{questa capacità è presente soltanto a partire dai kernel della serie 2.4.x.} -\footnotetext[22]{questa capacità è presente soltanto a partire dai kernel della +\footnotetext{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 @@ -3713,7 +3718,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 +3790,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} @@ -4856,7 +4864,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 -- 2.30.2