dell'amministratore a livello di sistema operativo, come \index{SELinux}
SELinux.
-Inoltre il meccanismo delle \textit{capabilities} è stato ulteriormente
-perfezionato nel kernel 2.6.25 rimovendo 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 set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26
-per consentire la rimozione non ripristinabile dei privilegi di
+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 intezioni originali dello standard
+POSIX, rimovendo 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
+ 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
-finisca per dipendere pesantemente dalla versione dello stesso e dal fatto che
-le nuove \textit{file capabilities} siano abilitate o meno. Per capire meglio
-la situazione e cosa è cambiato conviene allora spiegare con maggiori dettagli
+finisca per dipendere dalla versione dello stesso e dal fatto che le nuove
+\textit{file capabilities} siano abilitate o meno. Per capire meglio la
+situazione e cosa è cambiato conviene allora spiegare con maggiori dettagli
come funziona il meccanismo delle \textit{capabilities}.
Il primo passo per frazionare i privilegi garantiti all'amministratore,
supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
cui a ciascun processo sono stati associati tre distinti insiemi di
-\textit{capabilities}, 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
+\textit{capabilities}, denominati rispettivamente \textit{permitted},
+\textit{inheritable} ed \textit{effective}. 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 era, fino al kernel 2.6.25 definito come
intero a 32 bit per un massimo di 32 \textit{capabilities} distinte,
attualmente è stato aggiornato ad un vettore in grado di mantenerne fino a
- 64.} in cui ciascun bit corrisponde ad una capacità diversa.
+ 64.} 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:
+sez.~\ref{sec:proc_setuid}; il loro significato, che è rimasto sostanzialmente
+lo stesso anche dopo le modifiche seguite alla instroduzione delle
+\textit{file capabilities} è il seguente:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\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} o come
+ \textsl{ereditabili}. Se un processo cancella una capacità da questo insieme
+ non potrà più riassumerla.\footnote{questo è il comportamento più comune,
+ che prevede però una serie di eccezioni, dipendenti anche dal tipo di
+ supporto, che vedremo meglio in seguito dato il notevole intreccio nella
+ casistica.}
+\item[\textit{inheritable}] l'insieme delle \textit{capabilities}
+ ``\textsl{ereditabili}'', cioè di quelle che verranno trasmesse come insieme
+ delle \textsl{permesse} ad un nuovo programma eseguito attraverso una
+ chiamata ad \func{exec}.
\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).\footnote{e neanche in questo caso se
- vengono usate le estensioni introdotte con il kernel 2.6.26 che vedremo
- più avanti.}
-\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}
+Con l'introduzione delle \textit{file capabilities} sono stati introdotti
+altri tre insiemi associabili a ciascun file.\footnote{la realizzazione viene
+ eseguita con l'uso di uno specifico attributo esteso,
+ \texttt{security.capability}, la cui modifica è riservata, (come illustrato
+ in sez.~\ref{sec:file_xattr}) ai processi dotato della capacità
+ \macro{CAP\_SYS\_ADMIN}.} A differenza delle precedenti 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 di alcuni programmi con maggiori privilegi, in sostanza
+una estensione dell'uso del \acr{suid} di root. Anche questi tre insiemi sono
+identicati con gli stessi nomi, ma il loro significato è:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
+ delle capacità che con l'esecuzione del file verranno comunque aggiunte alle
+ capacità \textsl{permesse} del processo.
+\item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
+ l'insieme delle capacità che con l'esecuzione del file possono essere
+ ereditate dal processo originario (che cioè vengono tolte dalle
+ \textsl{ereditabili} del processo originale all'esecuzione di
+ \func{exec}).
+\item[\textit{effective}] in questo caso non si tratta di un insieme ma di un
+ unico valore logico; se attivo all'esecuzione del programma tutte le
+ capacità che risulterebbero \textsl{permesse} verranno pure attivate,
+ inserendole automaticamente nelle \textsl{effettive}, se disattivato nessuna
+ capacità verrà attivata (cioè le effettive restano vuote).
+\end{basedescript}
+
+Infine come accennato, esiste un altro insieme, il
+\itindex{capabilities~bounding~set} \textit{capabilities bounding set}, il cui
+scopo è quello di costituire un limite alle capacità che possono essere
+attivate per un processo, ma il suo significato è stato completamente
+modificato con l'introduzione delle \textit{file capabilities}.
+
+
+a meno che non sia dotato della capacità
+ \macro{CAP\_SETPCAP} nel qual caso potrà, come vedremo in seguito,
+ impostarne anche altre.
+
+che non esegua un programma che è \acr{suid} di root o
+ che ce l'ha nelle \textit{capabilities} presenti sul file
+ eseguibile.\footnote{e neanche in questo caso se vengono usate le estensioni
+ introdotte con il kernel 2.6.26 che vedremo più avanti.}
Fino al kernel 2.6.25 oltre a questi tre insiemi, che sono relativi al singolo
-processo, il kernel manteneva 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} era un parametro di sistema, accessibile
-attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che
-per questa sua caratteristica consentiva di impostare un limite generale alle
-capacità che possono essere accordate ai vari processi. Questo valore poteva
-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 poteva 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ù
+processo, il kernel manteneva un ulteriore insieme unico 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}
+venivano mascherati con un \textsl{AND} binario del contenuto corrente del
+\textit{capabilities bounding set}, così che il nuovo processo potesse
+disporre soltanto delle capacità in esso elencate.
+
+A lungo il \textit{capabilities bounding set} è stato un parametro generale di
+sistema, accessibile attraverso il contenuto del file
+\procfile{/proc/sys/kernel/cap-bound}, usato per impostare un limite
+universale alle capacità che possono essere accordate ai vari processi. Il
+suo valore poteva essere impostato 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, era in grado soltanto di rimuovere uno dei bit
+già presenti dell'insieme: questo significava che tolta una
+\textit{capability} dal \textit{capabilities bounding set} questa non era più
disponibile, neanche per l'amministratore, a meno di un riavvio.
+Qualora invece si sia abilitato nel kernel il supporto per le
+\textit{capabilities} dei file il \textit{capabilities bounding set} mantiene
+il suo significato di limite alle capacità che possono essere assegnate al
+processo, ma diventa una proprietà dello stesso (un quarto insieme che il
+processo si porta dietro). In questo
+
+
+
+ viene a costituire un doppio limite:
+
+
+
+
+
+
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
Access Control} 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
+ \const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei
processi.\\
\const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
\textit{accounting} dei processi (vedi
\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.\\
+ \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
(vedi sez.~\ref{sec:sys_time}).\\
\const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
projects / gapil.git / commitdiff