From fdbd17cde3c32139f572fb495ed1d48088f1457c Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 15 Aug 2011 22:31:15 +0000 Subject: [PATCH] Modifiche varie, aggiunte sulle capabilities. --- filedir.tex | 276 ++++++++++++++++++++++++++++++++++------------------ system.tex | 6 -- 2 files changed, 182 insertions(+), 100 deletions(-) diff --git a/filedir.tex b/filedir.tex index d9afc5c..da40afb 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,4 +1,4 @@ -%% filedir.tex +4%% filedir.tex %% %% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free @@ -16,10 +16,11 @@ In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono file e directory, iniziando dalle funzioni di libreria che si usano per copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che permette la manipolazione dei vari attributi di file e directory ed alla fine -faremo una trattazione dettagliata su come è strutturato il sistema base di -protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono -la gestione. Tutto quello che riguarda invece la manipolazione del contenuto -dei file è lasciato ai capitoli successivi. +prenderemo in esame la struttura di base del sistema delle protezioni e del +controllo dell'accesso ai file e le successive estensioni (\textit{Extended + Attributes}, ACL, quote disco, \textit{capabilities}). Tutto quello che +riguarda invece la manipolazione del contenuto dei file è lasciato ai capitoli +successivi. @@ -41,8 +42,8 @@ riguarda il comportamento e gli effetti delle varie funzioni. \label{sec:file_link} Una caratteristica comune a diversi sistemi operativi è quella di poter creare -dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows o i -nomi logici del VMS) che permettono di fare riferimento allo stesso file +dei nomi fittizi (come gli alias del vecchio MacOS o i collegamenti di Windows +o i nomi logici del VMS) che permettono di fare riferimento allo stesso file chiamandolo con nomi diversi o accedendovi da directory diverse. Questo è possibile anche in ambiente Unix, dove tali collegamenti sono @@ -4147,6 +4148,37 @@ ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con \itindend{Access~Control~List} +\subsection{La gestione delle quote disco} +\label{sec:disk_quota} + +Quella delle quote disco è una funzionalità introdotta inizialmente da BSD, e +presente in Linux fino dalla serie 2.0, che consente di porre dei tetti +massimi al consumo delle risorse di un filesystem (spazio disco e +\textit{inode}) da parte degli utenti e dei gruppi. Dato che la funzionalità +ha senso solo per i filesystem su cui si mantengono i dati degli +utenti\footnote{in genere la si attiva sul filesystem che contiene le + \textit{home} degli utenti, dato che non avrebbe senso per i file di sistema + che appartengono all'amministratore} essa deve essere abilitata +esplicitamente, questo si fa tramite due distinte opzioni di montaggio, +\texttt{usrquota} e \texttt{grpquota} che la attivano rispettivamente per gli +utenti e per i gruppi, cosa che consente di abilitare solo quelle che +interessano veramente. + +Il meccanismo prevede che per ciascun filesystem che supporta le quote (i vari +\textit{extN}, \textit{btrfs}, \textit{XFS}, \textit{JFS}, \textit{ReiserFS}) +il kernel provveda a mantenere i dati relativi al consumo delle risorse in due +file riservati,\footnote{la cosa vale per tutti i fileystem tranne + \textit{XFS} che mantiene i dati internamente; con la versione 2 del + supporto delle quote, l'unica rimasta in uso, questi file sono + \texttt{aquota.user} e \texttt{aquota.group} e si trovano nella directory + radice del filesytem su cui si sono attivate le quote.} e a + + +% TODO trattare quote disco +% vedi man quotactl + + + \subsection{La gestione delle \textit{capabilities}} \label{sec:proc_capabilities} @@ -4186,14 +4218,14 @@ 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; 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 +(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. Con questo supporto e con le ulteriori modifiche introdotte con il kernel 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente @@ -4230,13 +4262,13 @@ sono mantenuti i diversi insiemi di identificatori di 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}} +\begin{basedescript}{\desclabelwidth{2.1cm}\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 + non potrà più riassumerla.\footnote{questo nei casi ordinari, sono + previste 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} @@ -4255,78 +4287,109 @@ 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}} + \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 identicati con gli stessi +nomi, 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 file verranno comunque aggiunte alle + delle capacità che con l'esecuzione del programma verranno 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 + l'insieme delle capacità che con l'esecuzione del programma possono essere + ereditate dal processo originario (che cioè vengono tolte + dall'\textit{inheritable set} 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). + capacità verrà attivata (cioè l'\textit{effective set} resta vuoto). \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 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: - - +\itindbeg{capabilities~bounding~set} + +Infine come accennato, esiste un ulteriore insieme, chiamato +\textit{capabilities bounding set}, il cui scopo è quello di costituire un +limite alle capacità che possono essere attivate per un programma. Il suo +funzionamento però è stato notevolmente modificato con l'introduzione delle +\textit{file capabilities} e si deve pertanto prendere in considerazione una +casistica assai complessa. + +Per i kernel fino al 2.6.25, o se non si attiva il supporto per le +\textit{file capabilities}, il \textit{capabilities bounding set} è un +parametro generale di sistema, il cui valore viene riportato nel file +\procfile{/proc/sys/kernel/cap-bound}. Il suo valore iniziale è definito in +sede di compilazione del kernel, e da sempre ha previsto come default la +presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In +questa situazione solo il primo processo eseguito nel sistema (quello con +\textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di +modificarlo, ogni processo eseguito successivamente, anche se eseguito con +privilegi di amministratore,\footnote{per essere precisi occorreva la capacità + \const{CAP\_SYS\_MODULE}.} è in grado soltanto di rimuovere una delle +\textit{capabilities} già presenti dell'insieme. + +In questo caso l'effetto del \textit{capabilities bounding set} è che solo le +capacità in esso presenti possono essere trasmesse ad un altro programma +attraverso una \func{exec}. Questo in sostanza significa che se si elimina da +esso una capacità, considerato che \texttt{init} (almeno nelle versioni +ordinarie) non supporta la reimpostazione del \textit{bounding set}, questa +non sarà più disponibile per nessun processo a meno di un riavvio, eliminando +così in forma definitiva quella capacità per tutti, compreso +l'amministratore.\footnote{la qual cosa, visto il default usato per il + \textit{capabilities bounding set}, significa anche che \const{CAP\_SETPCAP} + non è stata praticamente mai usata nella sua forma orginale.} + +Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set} +è diventato una proprietà di ciascun processo, che viene propagata invariata +sia attraverso una \func{fork} che una \func{exec}. In questo caso il file +\procfile{/proc/sys/kernel/cap-bound} non esiste e \texttt{init} non ha nessun +ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la +presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}). + +Con questo nuovo meccanismo il \textit{bounding set} continua a ricoprire un +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. + +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à +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 +\textit{inheritable set} queste verrebbero assegnate. + +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} +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. + Quando un programma viene messo in esecuzione\footnote{cioè quando viene @@ -4365,10 +4428,10 @@ 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] +\begin{table}[!h!btp] \centering \footnotesize - \begin{tabular}{|l|p{11.5cm}|} + \begin{tabular}{|l|p{11.9cm}|} \hline \textbf{Capacità}&\textbf{Descrizione}\\ \hline @@ -4458,12 +4521,8 @@ che è opportuno dettagliare maggiormente. \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} & Prima del 2.6.24 la capacità di impostare o - rimuovere le \textit{capabilities} da un - processo, dopo quella di impostare una capacità - del \textit{bounding set} nelle proprie - \textit{inheritable} o rimoverla dal - \textit{bounding set} stesso.\\ + \const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle + \textit{capabilities}.\\ \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 @@ -4483,10 +4542,10 @@ che è opportuno dettagliare maggiormente. \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\_PTRACE}& La capacità di tracciare qualunque processo con + \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 + \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}).\\ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni @@ -4515,12 +4574,37 @@ che è opportuno dettagliare maggiormente. 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 + +Prima di dettagliare il significato della capacità più generiche, conviene +però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è +stato completamente cambiato con l'introduzione delle \textit{file + capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella +che permetteva al processo che la possedeva di impostare o rimuovere le +\textit{capabilities} che fossero presenti nel \textit{permitted set} del +chiamante di un qualunque altro processo. In realtà questo non è mai stato +l'uso inteso nelle bozze dallo standard POSIX, ed inoltre, come si è già +accennato, dato che questa capacità è assente nel \textit{capabilities + bounding set} usato di default, essa non è neanche mai stata realmente +disponibile. + +Con l'introduzione \textit{file capabilities} e il cambiamento del significato +del \textit{capabilities bounding set} la possibilità di modificare le +capacità di altri processi è stata completamente rimossa, e +\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo +significato originario, e cioè la capacità del processo di poter inserire nel +suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding + set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un +processo di eliminare una capacità dal proprio \textit{bounding set} (con la +conseguente impossibilità successiva di eseguire programmi con quella +capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. + +La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare +maggiormente è \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 @@ -4572,6 +4656,10 @@ 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}). +Questo modo di intendere ... da fare ... per cui +a partire dal 2.6.24/5 è divenuta quella di impostare una capacità del +\textit{bounding set} nelle proprie \textit{inheritable} o rimoverla dal +\textit{bounding set} stesso. Per la gestione delle \textit{capabilities} il kernel mette a disposizione due funzioni che permettono rispettivamente di leggere ed impostare i valori dei diff --git a/system.tex b/system.tex index 45e13e0..2c7cf2d 100644 --- a/system.tex +++ b/system.tex @@ -1816,12 +1816,6 @@ minimo indicato dal secondo valore (sempre in percentuale di spazio disco libero). Infine l'ultimo valore indica la frequenza in secondi con cui deve essere controllata detta percentuale. -% TODO trattare quote disco -% vedi man quotactl -%\section{La gestione delle quote disco} -%\label{sec:disk_quota} - - \section{La gestione dei tempi del sistema} \label{sec:sys_time} -- 2.30.2