\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
\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 è:
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
\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
\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
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
%
% 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}).\\
\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
\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}
\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
\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
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}
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
projects / gapil.git / commitdiff