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
\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
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
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}.
+
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:
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
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
% 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
% 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
% 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
projects / gapil.git / blobdiff