della sicurezza, passando poi a quelle relative all'analisi ed al controllo
dell'esecuzione, e alle funzioni per le modalità avanzate di creazione dei
processi e l'uso dei cosiddetti \textit{namespace}. Infine affronteremo le
-\textit{sytem call} attinenti ad una serie di funzionalità specialistiche come
+\textit{system call} attinenti ad una serie di funzionalità specialistiche come
la gestione della virgola mobile, le porte di I/O ecc.
\section{La gestione avanzata della sicurezza}
sez.~\ref{sec:file_ownership_management}).\\
\constd{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
permessi di lettura, scrittura ed esecuzione dei
- file, (vedi sez.~\ref{sec:file_access_control}).\\
+ file, (vedi
+ sez.~\ref{sec:file_access_control}).\\
\constd{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
permessi di lettura ed esecuzione per
le directory (vedi
\label{tab:proc_capabilities}
\end{table}
+% TODO: verificare ed aggiungere le nuove capacità CAP_BPF, CAP_PERFMON, vedi
+% https://lwn.net/Articles/822362/ anche CAP_CHECKPOINT_RESTORE vedi
+% https://lwn.net/Articles/822362/ e https://git.kernel.org/linus/74858abbb103
+
\constbeg{CAP\_SETPCAP}
Prima di dettagliare il significato della capacità più generiche, conviene
-
\subsection{La gestione del \textit{Secure Computing}.}
\label{sec:procadv_seccomp}
socket o una \textit{pipe}, creati prima di lanciare il processo che eseguirà
il codice non fidato.
+% TODO: a partire dal kernel 6.6 è stato introdotto
+% SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP that indicates that events from the
+% watched process will be handled synchronously; that allows the kernel to
+% schedule the two processes more efficiently (da LWN)
% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
+% sempre per seccomp vedi https://lwn.net/Articles/799557/ dal 5.11 supporto
+% per le constant-action bitmaps https://lwn.net/Articles/834785/
+% TODO un esempio di uso di seccomp è su
+% https://blog.cloudflare.com/sandboxing-in-linux-with-zero-lines-of-code/
\itindend{secure~computing~mode}
% TODO: trattare keyctl (man 2 keyctl)
-
+% (fare sezione dedicata ????)
+% TODO documentare la Crypto API del kernel
% TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
% pkey_mprotect, introdotte con il kernel 4.8, vedi
-% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
+% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
+
+% TODO documentare la syscall getrandom, introdotta con il kernel 3.17, vedi
+% http://lwn.net/Articles/606141/, ed introdotta con le glibc solo con la
+% versione 2.25 con getentropy, vedi https://lwn.net/Articles/711013/ ed i
+% problemi successivi vedi https://lwn.net/Articles/800509/
+
+%\subsection{La gestione delle chiavi crittografiche}
+%\label{sec:keyctl_management}
+
+% TODO non è chiaro se farlo qui, ma documentare la syscall bpf aggiunta con il
+% kernel 3.18, vedi http://lwn.net/Articles/612878/; al riguardo vedi anche
+% https://lwn.net/Articles/660331/
+
\section{Funzioni di gestione e controllo}
\label{sec:proc_manage_control}
%TODO: trattare PR_CAP_AMBIENT, dal 4.3
%TODO: trattare PR_CAP_FP_*, dal 4.0, solo per MIPS
-%TODO: trattare PR_MPX_*_MANAGEMENT, dal 3.19
+%TODO: trattare PR_MPX_*_MANAGEMENT, dal 3.19, vedi
+% https://lwn.net/Articles/582712/
%TODO: trattare PR_*NO_NEW_PRIVS, dal 3.5
+%TODO: trattare il core scheduling dal 5.14, vedi
+%https://lwn.net/Articles/780703/ e https://lwn.net/Articles/861251/
+%TODO: trattare PR_SPEC_L1D_FLUSH vedi https://git.kernel.org/linus/b7fe54f6c2d4
+
\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
\item[\constd{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
% TODO documentare PR_SPEC_DISABLE_NOEXEC in 5.1, vedi
% https://lwn.net/Articles/782511/
+% TODO documentare PR_SET_IO_FLUSHER in 5.6, vedi
+% https://lwn.net/Articles/811230/
+
+% TODO documentare PR_SET_SYSCALL_USER_DISPATCH in 5.11, vedi
+% https://lwn.net/Articles/826313/
+
+% TODO documentare PR_SET_MDWE in 6.3, vedi
+% https://git.kernel.org/linus/b507808ebce2
+
+
\label{sec:prctl_operation}
\end{basedescript}
+
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
\func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
stessa.
+% TODO trattare anche clone3 (vedi https://lwn.net/Articles/792628/), aggiunta
+% con il kernel 5.3
+% e aggiunte successive, col 5.5
+% il flag CLONE_CLEAR_SIGHAND
+% https://git.kernel.org/linus/49cb2fc42ce4
+% https://git.kernel.org/linus/41585bbeeef9
+
+
La necessità di avere uno \textit{stack} alternativo c'è solo quando si
intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
vede esattamente la stessa memoria del \textit{task}
\const{CLONE\_CHILD\_SETTID}.
La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
-\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
+\textit{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
un processo ordinario e non un \textit{thread}.
padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
questo significa che ogni \textit{file descriptor} aperto da un processo
verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
- \textit{file descriptor flag} di un \textit{file descriptor} verrà per
+ \textit{file descriptor flags} di un \textit{file descriptor} verrà per
entrambi.
Se non viene impostato il processo figlio eredita una copia della
\item[\constd{CLONE\_PARENT\_SETTID}]
\item[\constd{CLONE\_PID}]
+% TODO trattare CLONE_PIDFD introdotto con il kernel 5.2, vedi
+% https://lwn.net/Articles/787963/ e anche https://lwn.net/Articles/789023/
+
\item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
figlio viene tracciato.
% informazioni su setns qui: http://lwn.net/Articles/532748/
% http://lwn.net/Articles/531498/
-
+% TODO: se si applicano e ci stanno trattare gli argomenti di ioctl_ns
\section{Funzionalità avanzate e specialistiche}
\label{sec:process_special}
+% TODO: trattare userfaultfd, introdotta con il 4.23, vedi
+% http://man7.org/linux/man-pages/man2/userfaultfd.2.html,
+% https://lwn.net/Articles/787308/, https://git.kernel.org/linus/57e5d4f278b9,
+% e hardening della stessa (https://lwn.net/Articles/819834/) nel 5.11
+
+
+% TODO: trattare process_vm_readv/process_vm_writev introdotte con il kernel
+% 3.2, vedi http://man7.org/linux/man-pages/man2/process_vm_readv.2.html e i
+% precedenti tentativi https://lwn.net/Articles/405346/
+
\subsection{La gestione delle operazioni in virgola mobile}
\label{sec:process_fenv}
%
% TODO l'I/O sulle porte di I/O
-% consultare le manpage di ioperm, iopl e outb
+% consultare le manpage di ioperm, iopl e outb e
+% https://lwn.net/Articles/804143/
% non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
% fileintro ?)
+% emulata a partire dal kernel 5.5, vedi https://lwn.net/Articles/804143/
+%
Da fare
% vedi anche l'ulteriore opzione "expedited" introdotta con il kernel 4.14
% (https://lwn.net/Articles/728795/)
+% TODO trattare process_mrelease introdotta con il kernel 5.16, vedi:
+% https://lwn.net/Articles/864184/
+
%%% Local Variables:
% LocalWords: libcap lcap obj to text dup clear DIFFERS get ncap caps ssize
% LocalWords: argument length all setpcap from string name proc cat capgetp
% LocalWords: capsetp getcap read sigreturn sysctl protected hardlinks tmp
-% LocalWords: dell' symlink symlinks pathname TOCTTOU of
+% LocalWords: dell' symlink symlinks pathname TOCTTOU of execve attack kcmp