X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=c3a284b976ade0fc31a5f3c9af1c8a8ede170446;hb=a26655598e1260eeb528ded46724e977f3aafee0;hp=17ea1df01231fe09c52c243dc3d68a3a567028ac;hpb=930f4d0da83925a03ec2be420bbf671a6f5c9487;p=gapil.git

diff --git a/filedir.tex b/filedir.tex
index 17ea1df..c3a284b 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -4605,21 +4605,21 @@ 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
-(una sorta di \acr{suid} anch'esso parcellizzato); 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.
+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.
 
 Con questo supporto e con le ulteriori modifiche introdotte con il kernel
 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
-rivoluzionato, rendendolo più aderente alle intenzioni originali dello standard
-POSIX, rimuovendo il significato che fino ad allora aveva avuto la capacità
-\macro{CAP\_SETPCAP} e le modalità di funzionamento del cosiddetto
-\itindex{capabilities~bounding~set} \textit{capabilities bounding
+rivoluzionato, rendendolo più aderente alle intenzioni originali dello
+standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
+capacità \macro{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
+cosiddetto \itindex{capabilities~bounding~set} \textit{capabilities bounding
   set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
 consentire la rimozione non ripristinabile dei privilegi di
 amministratore. Questo fa sì che il significato ed il comportamento del kernel
@@ -4677,9 +4677,10 @@ altri tre insiemi associabili a ciascun file.\footnote{la realizzazione viene
   \macro{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
 soltanto quando il file che le porta viene eseguito come programma con una
 \func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
-con maggiori privilegi; in sostanza sono una sorta di estensione dell'uso del
-\acr{suid} di root.  Anche questi tre insiemi sono identificati con gli stessi
-nomi, ma il loro significato è diverso:
+con maggiori privilegi; in sostanza sono una sorta di estensione del
+\acr{suid} bit limitato ai privilegi di amministratore. Anche questi tre
+insiemi sono identificati con gli stessi nomi di quello dei processi, ma il
+loro significato è diverso:
 \begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
 \item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
   delle capacità che con l'esecuzione del programma verranno aggiunte alle
@@ -4741,14 +4742,14 @@ ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
 limite alle capacità che possono essere aggiunte al processo in quanto
 presenti nel \textit{permitted set} del programma messo in esecuzione, in
 sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
-suo \textit{permitted set} solo se questa è anche nel \textit{bounding
-  set}. In questo modo si possono rimuovere definitivamente certe capacità da
-un processo, anche qualora questo dovesse eseguire un programma
-privilegiato. 
+suo \textit{permitted set} (quello del file) solo se questa è anche nel
+\textit{bounding set} (del processo). In questo modo si possono rimuovere
+definitivamente certe capacità da un processo, anche qualora questo dovesse
+eseguire un programma privilegiato che prevede di riassegnarle.
 
 Si tenga presente però che in questo caso il \textit{bounding set} blocca
 esclusivamente le capacità indicate nel \textit{permitted set} del programma
-che verrebbero attivate in caso di esecuzione, non quelle eventualmente già
+che verrebbero attivate in caso di esecuzione, e non quelle eventualmente già
 presenti nell'\textit{inheritable set} del processo (ad esempio perché
 presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
 eseguendo un programma che abbia anche lui dette capacità nel suo
@@ -4756,26 +4757,70 @@ eseguendo un programma che abbia anche lui dette capacità nel suo
 
 In questa seconda versione inoltre il \textit{bounding set} costituisce anche
 un limite per le capacità che possono essere aggiunte all'\textit{inheritable
-  set} del processo con \func{capset}, sempre nel senso che queste devono
-essere presenti nel \textit{bounding set} oltre che nel \textit{permitted set}
-del processo.
- 
-\itindend{capabilities~bounding~set}
- 
+  set} del processo stesso con \func{capset}, sempre nel senso che queste
+devono essere presenti nel \textit{bounding set} oltre che nel
+\textit{permitted set} del processo. Questo limite vale anche per processi con
+i privilegi di amministratore,\footnote{si tratta sempre di avere la
+  \textit{capability} \const{CAP\_SETPCAP}.} per i quali non vale la
+condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
+  set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
+  scopo anche in questo caso è ottenere una rimozione definitiva della
+  possibilità di passare una capacità rimossa dal \textit{bounding set}.}
+
 Come si può notare per fare ricorso alle \textit{capabilities} occorre
 comunque farsi carico di una notevole complessità di gestione, aggravata dalla
 presenza di una radicale modifica del loro funzionamento con l'introduzione
 delle \textit{file capabilities}. Considerato che il meccanismo originale era
 incompleto e decisamente problematico nel caso di programmi che non ne
-sappiano tener conto,\footnote{si ebbe un grosso problema di sicurezza con
-  \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
-  dall'\textit{inheritable set} si ottenne di far fallire una \func{setuid},
-  in maniera inaspettata per il programma (che aspettandosi il successo della
-  funzione non ne controllava lo stato di uscita) con la conseguenza di
-  effettuare come amministratore operazioni che altrimenti sarebbero state
-  eseguite, senza poter apportare danni, da utente normale.}  ci soffermeremo
-solo sulla implementazione completa presente a partire dal kernel 2.6.25,
-tralasciando ulteriori dettagli riguardo la versione precedente.
+sappessero tener conto,\footnote{si ebbe un grosso problema di sicurezza con
+  \texttt{sendmail}: riuscendo a rimuovere \const{CAP\_SETGID}
+  dall'\textit{inheritable set} di un processo si ottenne di far fallire
+  \func{setuid} in maniera inaspettata per il programma (che aspettandosi
+  sempre il successo della funzione non ne controllava lo stato di uscita) con
+  la conseguenza di effettuare come amministratore operazioni che altrimenti
+  sarebbero state eseguite, senza poter apportare danni, da utente normale.}
+ci soffermeremo solo sulla implementazione completa presente a partire dal
+kernel 2.6.25, tralasciando ulteriori dettagli riguardo la versione
+precedente.
+
+Riassumendo le regole finora illustrate tutte le \textit{capabilities} vengono
+ereditate senza modifiche attraverso una \func{fork} mentre, indicati con
+\texttt{orig\_*} i valori degli insiemi del processo chiamante, con
+\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
+\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
+processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
+formula (espressa in pseudocodice C) di fig.~\ref{fig:cap_across_exec}; si
+noti come in particolare il \textit{capabilities bounding set} non viene
+comunque modificato e resta lo stesso sia attraverso una \func{fork} che
+attraverso una \func{exec}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{12cm}
+    \includecodesnip{listati/cap-results.c}
+  \end{minipage}
+  \caption{Espressione della modifica delle \textit{capabilities} attraverso
+    una \func{exec}.}
+  \label{fig:cap_across_exec}
+\end{figure}
+
+\itindend{capabilities~bounding~set}
+
+A queste regole se ne aggiungono delle altre che servono a riprodurre il
+comportamento tradizionale di un sistema unix-like quando viene eseguito un
+file senza \textit{capabilities}, se si applicassero sempre così infatti, non
+essendo definite delle capacità né nel \textit{permitted set} né
+nell'\textit{inheritable set} del file, anche l'amministratore perderebbe
+tutti i privilegi eventualmente avuti dal processo.
+
+Per questo motivo se un programma senza \textit{capabilities} viene eseguito
+da un processo con \textit{real user-ID} 0, o se ha attivo il \acr{suid} bit
+ed appartiene all'amministratore, esso viene trattato come se tanto il
+\textit{permitted set} che l'\textit{inheritable set} fossero con tutte le
+\textit{capabilities} abilitate, e con l'\textit{effective set} attivo, col
+risultato di fornire comunque al processo tutte le capacità presenti nel
+proprio \textit{bounding set}.
+
 
 
 
@@ -4790,8 +4835,7 @@ 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.
+\textit{inherited}. 
 
 
 % TODO verificare per process capability bounding set, vedi:
@@ -4931,10 +4975,10 @@ che è opportuno dettagliare maggiormente.
                               sez.~\ref{sec:sys_bsd_accounting}).\\ 
     \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
                               \func{ptrace} (vedi 
-                              sez.~\ref{sec:xxx_ptrace}).\\
+                              sez.~\ref{sec:process_ptrace}).\\
     \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
                               di I/O con \func{ioperm} e \func{iopl} (vedi
-                              sez.~\ref{sec:file_io_port}).\\
+                              sez.~\ref{sec:process_io_port}).\\
     \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
                               sulle risorse.\\ 
     \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema
@@ -5020,9 +5064,8 @@ 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}).
+sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie}, 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
@@ -5472,14 +5515,14 @@ funzione.
 
 % TODO vedi http://lwn.net/Articles/198557/ e 
 % http://www.madore.org/~david/linux/newcaps/
-% TODO documentare prctl ...
+
 
 
 \subsection{La funzione \func{chroot}}
 \label{sec:file_chroot}
 
 % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
-% dentro chroot SELinux e AppArmor ???
+% dentro chroot SELinux e AppArmor, Tomoyo, Smack, cgroup o che altro ???
 
 Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
 \func{chroot} viene usata spesso per restringere le capacità di accesso di un
@@ -5616,7 +5659,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  setresuid setfsuid IMMUTABLE immutable append only BIND SERVICE
 % LocalWords:  BROADCAST broadcast multicast multicasting RAW PACKET IPC LOCK
 % LocalWords:  memory mlock mlockall shmctl mmap MODULE RAWIO ioperm iopl PACCT
-% LocalWords:  PTRACE ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup
+% LocalWords:  ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup
 % 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
@@ -5627,11 +5670,11 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  QUOTAON ENODEV ENOPKG ENOTBLK GETQUOTA SETQUOTA SETUSE SETQLIM
 % LocalWords:  forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
 % LocalWords:  REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
+% LocalWords:  QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
+% LocalWords:  INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
+% LocalWords:  Python Truelite Srl quotamodule Repository who
 
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
-% LocalWords:  QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
-% LocalWords:  INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
-% LocalWords:  Python Truelite Srl quotamodule Repository who