X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=8e93228a4e386834ce53df2f883d5aaa566ebf41;hb=e14c16e9341a6baa99b5e93f733150ba72dfce96;hp=c3a284b976ade0fc31a5f3c9af1c8a8ede170446;hpb=af4cf2bcebfaf023cc182b8370b978194e8027f7;p=gapil.git diff --git a/filedir.tex b/filedir.tex index c3a284b..8e93228 100644 --- a/filedir.tex +++ b/filedir.tex @@ -4687,14 +4687,14 @@ loro significato è diverso: capacità \textsl{permesse} del processo. \item[\textit{inheritable}] (chiamato originariamente \textit{allowed}) l'insieme delle capacità che con l'esecuzione del programma possono essere - ereditate dal processo originario (che cioè vengono tolte + ereditate dal processo originario (che cioè non 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è l'\textit{effective set} resta vuoto). + capacità verrà attivata (cioè l'\textit{effective set} resterà vuoto). \end{basedescript} \itindbeg{capabilities~bounding~set} @@ -4714,21 +4714,22 @@ 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 originale.} +modificarlo; ogni processo eseguito successivamente, se dotato dei privilegi +di amministratore, è in grado soltanto di rimuovere una delle +\textit{capabilities} già presenti dell'insieme.\footnote{per essere precisi + occorreva la capacità \const{CAP\_SYS\_MODULE}.} + +In questo caso l'effetto complessivo 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 un +qualunque programma 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 + originale.} 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 @@ -4761,7 +4762,7 @@ un limite per le capacità che possono essere aggiunte all'\textit{inheritable 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 + \textit{capability} \const{CAP\_SETPCAP}.} per i quali invece 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 @@ -4772,8 +4773,8 @@ 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 -sappessero tener conto,\footnote{si ebbe un grosso problema di sicurezza con - \texttt{sendmail}: riuscendo a rimuovere \const{CAP\_SETGID} +sapessero tener conto,\footnote{c'è stato 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 @@ -4789,7 +4790,7 @@ ereditate senza modifiche attraverso una \func{fork} mentre, indicati 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 +formula (espressa in pseudo-codice 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}. @@ -4807,36 +4808,143 @@ attraverso una \func{exec}. \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}. - - - +comportamento tradizionale di un sistema unix-like in tutta una serie di +circostanze. La prima di queste è relativa a quello che avviene quando si +esegue un file senza \textit{capabilities}; se infatti si considerasse questo +equivalente al non averne assegnata alcuna, non essendo presenti capacità né +nel \textit{permitted set} né nell'\textit{inheritable set} del file, +nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i +privilegi originali dal processo. + +Per questo motivo se un programma senza \textit{capabilities} assegnate viene +eseguito da un processo con \textit{real user-ID} 0, esso verrà trattato come +se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con +tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo, +col risultato di fornire comunque al processo tutte le capacità presenti nel +proprio \textit{bounding set}. Lo stesso avviene quando l'eseguibile ha attivo +il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si +riesce così a riottenere il comportamento classico di un sistema unix-like. + +Una seconda circostanza è quella relativa a cosa succede alle +\textit{capabilities} di un processo nelle possibili transizioni da +\textit{user-ID} nullo a \textit{user-ID} non nullo o viceversa (corrispondenti +rispettivamente a cedere o riottenere i i privilegi di amministratore) che si +possono effettuare con le varie funzioni viste in +sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto +complessa, considerata anche la presenza dei diversi gruppi di identificatori +illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che: +\begin{enumerate*} +\item se si passa da \textit{effective user-ID} nullo a non nullo + l'\textit{effective set} del processo viene totalmente azzerato, se + viceversa si passa da \textit{effective user-ID} non nullo a nullo il + \textit{permitted set} viene copiato nell'\textit{effective set}; +\item se si passa da \textit{file system user-ID} nullo a non nullo verranno + cancellate dall'\textit{effective set} del processo tutte le capacità + attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD}, + \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH}, + \const{CAP\_MAC\_OVERRIDE}, \const{CAP\_CHOWN}, \const{CAP\_FSETID} e + \const{CAP\_FOWNER} (le prime due a partire dal kernel 2.2.30), nella + transizione inversa verranno invece inserite nell'\textit{effective set} + quelle capacità della precedente lista che sono presenti nel suo + \textit{permitted set}. +\item se come risultato di una transizione riguardante gli identificativi dei + gruppi \textit{real}, \textit{saved} ed \textit{effective} in cui si passa + da una situazione in cui uno di questi era nullo ad una in cui sono tutti + non nulli,\footnote{in sostanza questo è il caso di quando si chiama + \func{setuid} per rimuovere definitivamente i privilegi di amministratore + da un processo.} verranno azzerati completamente sia il \textit{permitted + set} che l'\textit{effective set}. +\end{enumerate*} +\label{sec:capability-uid-transition} + +La combinazione di tutte queste regole consente di riprodurre il comportamento +ordinario di un sistema di tipo Unix tradizionale, ma può risultare +problematica qualora si voglia passare ad una configurazione di sistema +totalmente basata sull'applicazione delle \textit{capabilities}; in tal caso +infatti basta ad esempio eseguire un programma con \acr{suid} bit di proprietà +dell'amministratore per far riottenere ad un processo tutte le capacità +presenti nel suo \textit{bounding set}, anche se si era avuta la cura di +cancellarle dal \textit{permitted set}. + +\itindbeg{securebits} + +Per questo motivo a partire dal kernel 2.6.26, se le \textit{file + capabilities} sono abilitate, ad ogni processo viene stata associata una +ulteriore maschera binaria, chiamata \textit{securebits flags}, il cui sono +mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui +valore consente di modificare queste regole speciali che si applicano ai +processi con \textit{user-ID} nullo. La maschera viene sempre mantenuta +attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre +cancellato il flag \const{SECURE\_KEEP\_CAPS}. -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 -(nel senso che assume negli insiemi \textit{effective} e \textit{permitted}) -le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che -non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata -eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma -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}. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}{|l|p{10cm}|} + \hline + \textbf{Flag} & \textbf{Descrizione} \\ + \hline + \hline + \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle + sue \textit{capabilities} quando tutti i suoi + \textit{user-ID} passano ad un valore non + nullo (regola di compatibilità per il cambio + di \textit{user-ID} n. 3 del precedente + elenco), sostituisce il precedente uso + dell'operazione \const{PR\_SET\_KEEPCAPS} di + \func{prctl}.\\ + \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche + delle sue \textit{capabilities} nel passaggio + da nullo a non nullo degli \textit{user-ID} + dei gruppi \textit{effective} e + \textit{file system} (regole di compatibilità + per il cambio di \textit{user-ID} nn. 1 e 2 del + precedente elenco).\\ + \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità + aggiuntiva quando esegue un programma, anche + se ha \textit{user-ID} nullo o il programma ha + il \acr{suid} bit attivo ed appartiene + all'amministratore (regola di compatibilità + per l'esecuzione di programmi senza + \textit{capabilities}).\\ + \hline + \end{tabular} + \caption{Costanti identificative dei flag che compongono la maschera dei + \textit{securebits}.} + \label{tab:securebits_values} +\end{table} +A ciascuno dei flag di tab.~\ref{tab:securebits_values} è inoltre abbinato un +corrispondente flag di blocco, identificato da una costante omonima con +l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha +l'effetto di rendere permanente l'impostazione corrente del corrispondente +flag ordinario; in sostanza con \const{SECURE\_KEEP\_CAPS\_LOCKED} si rende +non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con +\const{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per +\const{SECURE\_NO\_SETUID\_FIXUP} e con \const{SECURE\_NOROOT\_LOCKED} per +\const{SECURE\_NOROOT}. + +Per l'impostazione di questi flag sono stata predisposte due specifiche +operazioni di \func{prctl} (vedi sez.~\ref{sec:process_prctl}), +\const{PR\_GET\_SECUREBITS}, che consente di ottenerne il valore, e +\const{PR\_SET\_SECUREBITS}, che consente di modificarne il valore; per +quest'ultima sono comunque necessari i privilegi di amministratore ed in +particolare la capacità \const{CAP\_SETPCAP}. Prima dell'introduzione dei +\textit{securebits} era comunque possibile ottenere lo stesso effetto di +\const{SECURE\_KEEP\_CAPS} attraverso l'uso di un'altra operazione di +\func{prctl}, \const{PR\_SET\_KEEPCAPS}. + +\itindend{securebits} + +Oltre alla gestione dei \textit{securebits} la nuova versione delle +\textit{file capabilities} prevede l'uso di \func{prctl} anche per la gestione +del \textit{capabilities bounding set}, attraverso altre due operazioni +dedicate, \const{PR\_CAPBSET\_READ} per controllarne il valore e +\const{PR\_CAPBSET\_DROP} per modificarlo; quest'ultima di nuovo è una +operazione privilegiata che richiede la capacità \const{CAP\_SETPCAP} e che, +come indica chiaramente il nome, permette solo la rimozione di una +\textit{capability} dall'insieme; per i dettagli sull'uso di tutte queste +operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}. % 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 @@ -4955,13 +5063,11 @@ che è opportuno dettagliare maggiormente. \const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle \textit{capabilities}.\\ \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti - amministrativi. \\ + amministrativi.\\ \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del - sistema.\\ -% TODO trattare reboot e kexec + sistema (vedi sez.~\ref{sec:sys_reboot}).\\ \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione - \func{chroot} (vedi - sez.~\ref{sec:file_chroot}).\\ + \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\ \const{CAP\_MAC\_ADMIN} & La capacità amministrare il \textit{Mandatory Access Control} di Smack (dal kernel 2.6.25).\\ \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il \textit{Mandatory @@ -4969,7 +5075,7 @@ che è opportuno dettagliare maggiormente. \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del kernel.\\ \const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei - processi.\\ + processi (vedi sez.~\ref{sec:proc_priority}).\\ \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di \textit{accounting} dei processi (vedi sez.~\ref{sec:sys_bsd_accounting}).\\ @@ -5524,6 +5630,9 @@ funzione. % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con % dentro chroot SELinux e AppArmor, Tomoyo, Smack, cgroup o che altro ??? +% inserire setns (introdotta con il 3.0, vedi http://lwn.net/Articles/407495/) +% e le funzionalità di isolamento dei container + 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 programma ad una sezione limitata del filesystem, per cui ne parleremo in @@ -5653,14 +5762,14 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: INDENT major number IDE Documentation makedev proc copy LNK long % LocalWords: euidaccess eaccess delete def tag qualifier permset calendar NOW % LocalWords: mutt noatime relatime strictatime atim nsec mtim ctim atimensec -% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT +% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT PR % LocalWords: utimensat timespec sec futimesat LIDS DAC OVERRIDE SEARCH chattr % LocalWords: Discrectionary KILL SETGID domain SETUID setuid setreuid SETPCAP % 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 accounting NICE RESOURCE TTY CONFIG hangup vhangup -% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND +% LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup dell' +% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND nn % LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef % LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm % LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT @@ -5672,7 +5781,8 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % 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 +% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP +% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I %%% Local Variables: %%% mode: latex