From: Simone Piccardi Date: Sun, 21 Aug 2011 19:37:55 +0000 (+0000) Subject: Definizione nuova sezione per clone, prctl, ptrace. Correzioni varie e X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=af4cf2bcebfaf023cc182b8370b978194e8027f7;p=gapil.git Definizione nuova sezione per clone, prctl, ptrace. Correzioni varie e prosucuzione del lavoro sulle capabilities. --- diff --git a/fileadv.tex b/fileadv.tex index 38f01fc..2c4b09a 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -8,6 +8,7 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% + \chapter{La gestione avanzata dei file} \label{cha:file_advanced} In questo capitolo affronteremo le tematiche relative alla gestione avanzata @@ -189,11 +190,12 @@ riportate in tab.~\ref{tab:file_flock_operation}. \end{table} I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di -richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera -alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si -bloccherà qualora il \textit{file lock} non possa essere acquisito, ma -ritornerà subito con un errore di \errcode{EWOULDBLOCK}. Per rilasciare un -\textit{file lock} si dovrà invece usare \const{LOCK\_UN}. +richiedere un \textit{file lock} rispettivamente condiviso o esclusivo, ed +ovviamente non possono essere usati insieme. Se con essi si specifica anche +\const{LOCK\_NB} la funzione non si bloccherà qualora il \textit{file lock} +non possa essere acquisito, ma ritornerà subito con un errore di +\errcode{EWOULDBLOCK}. Per rilasciare un \textit{file lock} si dovrà invece +usare direttamente const{LOCK\_UN}. Si tenga presente che non esiste una modalità per eseguire atomicamente un cambiamento del tipo di blocco (da \textit{shared lock} a \textit{esclusive @@ -470,7 +472,7 @@ voce nella \itindex{file~table} \textit{file table}, ma con il valore del \acr{pid} del processo. \begin{figure}[!bht] - \centering \includegraphics[width=13cm]{img/file_posix_lock} + \centering \includegraphics[width=12cm]{img/file_posix_lock} \caption{Schema dell'architettura del \textit{file locking}, nel caso particolare del suo utilizzo secondo l'interfaccia standard POSIX.} \label{fig:file_posix_lock} @@ -5404,11 +5406,6 @@ livello di kernel. -%\subsection{L'utilizzo delle porte di I/O} -%\label{sec:file_io_port} -% -% TODO l'I/O sulle porte di I/O -% consultare le manpage di ioperm, iopl e outb % TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi % http://lwn.net/Articles/432757/ 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 diff --git a/prochand.tex b/prochand.tex index 8113d7f..be5e976 100644 --- a/prochand.tex +++ b/prochand.tex @@ -670,7 +670,7 @@ Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio; \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio; -\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:prctl_xxx}) che +\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che notifica al figlio la terminazione del padre viene cancellata; \item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}). @@ -1032,11 +1032,11 @@ quando un processo figlio entra nello stato \textit{stopped}\footnote{in realtà viene notificato soltanto il caso in cui il processo è stato fermato da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi - sez.~\ref{sec:xxx_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), mentre -con \const{WCONTINUED} la funzione ritorna quando un processo in stato + sez.~\ref{sec:process_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), +mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato \textit{stopped} riprende l'esecuzione per la ricezione del segnale \const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è -dettagliato in sez.~\ref{sec:sess_ctrl_term}). +dettagliato in sez.~\ref{sec:sess_ctrl_term}). La terminazione di un processo figlio (così come gli altri eventi osservabili con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione @@ -1539,11 +1539,11 @@ nell'esecuzione della funzione \func{exec}, queste sono: sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi; \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi - sez.~\ref{sec:prctl_xxx}) a meno che il programma da eseguire non sia + sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} (vedi sez.~\ref{sec:proc_access_id}); \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi - sez.~\ref{sec:prctl_xxx}) viene cancellato; + sez.~\ref{sec:process_prctl}) viene cancellato; \item il nome del processo viene impostato al nome del file contenente il programma messo in esecuzione; \item il segnale di terminazione viene reimpostato a \const{SIGCHLD}; @@ -3262,11 +3262,14 @@ dei processi che gli appartengono,\footnote{per la modifica delle priorità di altri processi occorrono privilegi amministrativi, ed in particolare la capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).} cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del -chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo +chiamante. Data la possibilità di ottenere un blocco totale del sistema, solo l'amministratore\footnote{o un processo con la capacità \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può impostare un processo ad una priorità di I/O nella classe -\const{IOPRIO\_CLASS\_RT} o \const{IOPRIO\_CLASS\_IDLE}. +\const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la +classe \const{IOPRIO\_CLASS\_IDLE} fino al kernel 2.6.24, ma dato che in +questo caso non ci sono effetti sugli altri processi questo limite è stato +rimosso a partire dal kernel 2.6.25. %TODO verificare http://lwn.net/Articles/355987/ @@ -3274,6 +3277,40 @@ impostare un processo ad una priorità di I/O nella classe % vedi man numa e le pagine di manuale relative % vedere anche dove metterle... + +\section{Funzioni di gestione avanzata} +\label{sec:proc_advanced_control} + +Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che +attengono alla gestione ordinaria dei processi e delle loro proprietà più +comuni. Tratteremo qui alcune \textit{system call} specialistiche dedicate +alla gestione di alcune funzionalità specifiche ed avanzate il cui uso è in +genere piuttosto ridotto. + +\subsection{La system call \func{clone}} +\label{sec:process_clone} + +Da fare + +\subsection{La funzione \func{prctl}} +\label{sec:process_prctl} + +Da fare + +\subsection{La funzione \func{ptrace}} +\label{sec:process_ptrace} + +Da fare + +\subsection{L'accesso alle porte di I/O} +\label{sec:process_io_port} + +% +% TODO l'I/O sulle porte di I/O +% consultare le manpage di ioperm, iopl e outb + +Da fare + \section{Problematiche di programmazione multitasking} \label{sec:proc_multi_prog} diff --git a/system.tex b/system.tex index 2c7cf2d..12ed77c 100644 --- a/system.tex +++ b/system.tex @@ -559,7 +559,7 @@ lettura. Affronteremo questi argomenti in questa sezione, insieme alle funzioni che si usano per il controllo di altre caratteristiche generali del sistema, come quelle per la gestione dei filesystem e di utenti e gruppi. -% TODO ristrutturare e aggiungere \func{prctl} +% TODO ristrutturare ? \subsection{La funzione \func{sysctl} ed il filesystem \file{/proc}} \label{sec:sys_sysctl} diff --git a/thread.tex b/thread.tex index 8cc4fac..39c1f16 100644 --- a/thread.tex +++ b/thread.tex @@ -61,9 +61,6 @@ dei processi: \label{sec:linux_thread} -\subsection{La system call \func{clone}} -\label{sec:process_clone} - \subsection{Implementazioni alternative}