Domande più simili con più risposte che meritano attenzione:
NOTA: alcune delle risposte lì indicano soluzioni specifiche non ancora menzionate qui.
In realtà, ci sono alcuni strumenti di jailing con diverse implementazioni, ma molti di essi non sono sicuri in base alla progettazione (come fakeroot, LD_PRELOADbasati su), o non completi (come fakeroot-ng, ptracebasati su), o richiedono root ( chrooto plashmenzionati in fakechroot etichetta di avvertimento ).
Questi sono solo esempi; Ho pensato di elencarli tutti fianco a fianco, con l'indicazione di queste 2 funzionalità ("si può fidare?", "Richiede il root da configurare?"), Forse alle implementazioni di virtualizzazione a livello di sistema operativo .
In generale, le risposte lì coprono l'intera gamma descritta di possibilità e anche di più:
macchine virtuali / SO
estensione del kernel (come SELinux)
- (menzionato nei commenti qui),
chroot
Helpers basati su Chroot (che tuttavia devono essere setUID root, perché chrootrichiedono root; o forse chrootpotrebbero funzionare in uno spazio dei nomi isolato - vedi sotto):
[per dirne un po 'di più!]
Strumenti di isolamento noti basati su chroot:
- hasher con i suoi
hsh-rune hsh-shellcomandi. ( Hasher è stato progettato per la creazione di software in modo sicuro e ripetibile.)
- Schroot menzionato in un'altra risposta
- ...
ptrace
Un'altra affidabile soluzione di isolamento (oltre a seccompquella basata su basi ) sarebbe la completa intercettazione di syscall ptrace, come spiegato nella manpage per fakeroot-ng:
A differenza delle implementazioni precedenti, fakeroot-ng utilizza una tecnologia che non lascia scelta al processo tracciato se utilizzerà o meno i "servizi" di fakeroot-ng. Compilare staticamente un programma, chiamare direttamente il kernel e manipolare il proprio spazio di indirizzi sono tutte tecniche che possono essere banalmente usate per bypassare il controllo basato su LD_PRELOAD su un processo e non si applicano a fakeroot-ng. È teoricamente possibile modellare il fakeroot-ng in modo tale da avere il controllo totale sul processo tracciato.
Mentre è teoricamente possibile, non è stato fatto. Fakeroot-ng presume certe ipotesi "ben educate" sul processo da rintracciare e un processo che rompa tali ipotesi potrebbe essere in grado, se non del tutto fuggire, almeno eludere alcuni degli ambienti "falsi" imposti da fakeroot- ng. Pertanto, sei fortemente avvisato di non utilizzare fakeroot-ng come strumento di sicurezza. Le segnalazioni di bug che affermano che un processo può deliberatamente (anziché inavvertitamente) sfuggire al controllo di fake-root-ng verrà chiuso come "non un bug" o contrassegnato come bassa priorità.
È possibile che questa politica venga ripensata in futuro. Per il momento, tuttavia, sei stato avvertito.
Tuttavia, come puoi leggerlo, fakeroot-ngnon è progettato per questo scopo.
(A proposito, mi chiedo perché abbiano scelto di usare l' seccompapproccio basato su Chromium piuttosto che un ptracebasato su ...)
Degli strumenti non menzionati sopra, ho notato Geordi da solo, perché mi piaceva che il programma di controllo fosse scritto in Haskell.
Strumenti di isolamento noti basati su ptrace:
seccomp
Un modo noto per ottenere l'isolamento è attraverso l'approccio seccomp sandbox utilizzato in Google Chromium . Ma questo approccio suppone che tu scriva un aiutante che elabori alcuni (quelli consentiti) dell'accesso al file "intercettato" e altri syscall; e, naturalmente, anche sforzarsi di "intercettare" i syscalls e reindirizzarli verso l'helper (forse, significherebbe persino una cosa come sostituire i syscalls intercettati nel codice del processo controllato; quindi, non suona per essere piuttosto semplice; se sei interessato, è meglio leggere i dettagli piuttosto che solo la mia risposta).
Altre informazioni correlate (da Wikipedia):
(L'ultimo elemento sembra essere interessante se si sta cercando una seccompsoluzione di base generale al di fuori di Chromium. C'è anche un post sul blog che vale la pena di leggere dall'autore di "seccomp-nurse": SECCOMP come soluzione di sandboxing?. )
L'illustrazione di questo approccio dal progetto "seccomp-nurse" :
Un seccomp "flessibile" possibile nel futuro di Linux?
Nel 2009 apparivano anche suggerimenti per patchare il kernel di Linux in modo che ci fosse più flessibilità nella seccompmodalità - in modo che "molte delle acrobazie di cui abbiamo bisogno attualmente possano essere evitate". ("Acrobatica" si riferisce alle complicazioni legate alla scrittura di un aiutante che deve eseguire molte sospette forse innocenti per conto del processo incarcerato e di sostituire le scaglie eventualmente innocenti nel processo incarcerato.) Un articolo di LWN ha scritto a questo punto:
Un suggerimento che è emerso è stato quello di aggiungere una nuova "modalità" a seccomp. L'API è stata progettata con l'idea che applicazioni diverse potrebbero avere requisiti di sicurezza diversi; include un valore "mode" che specifica le restrizioni che dovrebbero essere messe in atto. Solo la modalità originale è mai stata implementata, ma sicuramente è possibile aggiungerne altre. La creazione di una nuova modalità che consentiva al processo di avvio di specificare quali chiamate di sistema sarebbero consentite renderebbe la struttura più utile per situazioni come la sandbox di Chrome.
Adam Langley (anche lui di Google) ha pubblicato una patch che fa proprio questo. La nuova implementazione "mode 2" accetta una maschera di bit che descrive quali chiamate di sistema sono accessibili. Se uno di questi è prctl (), il codice sandbox può limitare ulteriormente le proprie chiamate di sistema (ma non può ripristinare l'accesso alle chiamate di sistema che sono state negate). Tutto sommato, sembra una soluzione ragionevole che potrebbe semplificare la vita agli sviluppatori di sandbox.
Detto questo, questo codice potrebbe non essere mai unito perché la discussione da allora è passata ad altre possibilità.
Questo "seccomp flessibile" avvicinerebbe le possibilità di Linux a fornire la funzionalità desiderata nel sistema operativo, senza la necessità di scrivere helper così complicati.
(Un post sul blog con sostanzialmente lo stesso contenuto di questa risposta: http://geofft.mit.edu/blog/sipb/33 .)
spazi dei nomi ( unshare)
L'isolamento tramite spazi dei nomi ( unsharesoluzioni basate su base ) - non menzionato qui - ad esempio, i mount-point di condivisione (combinati con FUSE?) Potrebbero forse far parte di una soluzione funzionante per chi desidera limitare l'accesso al filesystem dei processi non attendibili.
Più sugli spazi dei nomi, ora, poiché la loro implementazione è stata completata (questa tecnica di isolamento è nota anche con il nome "Linux Containers", o "LXC" , non è vero? ..):
"Uno degli obiettivi generali degli spazi dei nomi è supportare l'implementazione di container, uno strumento per la virtualizzazione leggera (oltre che per altri scopi)" .
È anche possibile creare un nuovo spazio dei nomi utente, in modo che "un processo possa avere un normale ID utente non privilegiato all'esterno di uno spazio dei nomi utente e allo stesso tempo avere un ID utente di 0 all'interno dello spazio dei nomi. Ciò significa che il processo ha i privilegi di root completi per le operazioni all'interno dello spazio dei nomi utente, ma non è privilegiato per le operazioni all'esterno dello spazio dei nomi ".
Per comandi reali funzionanti per fare ciò, vedere le risposte su:
e speciale programmazione / compilazione dello spazio utente
Ma, naturalmente, le garanzie "jail" desiderate sono implementabili mediante la programmazione nello spazio utente ( senza supporto aggiuntivo per questa funzionalità dal sistema operativo ; forse è per questo che questa funzionalità non è stata inclusa in primo luogo nella progettazione dei sistemi operativi ); con più o meno complicazioni.
Il citato ptrace- o seccompsandboxing basata su può essere visto come alcune varianti di attuare le garanzie scrivendo una sandbox-helper che controllare gli altri processi, che sarebbero stati trattati come "scatole nere", arbitrario programmi Unix.
Un altro approccio potrebbe essere quello di utilizzare tecniche di programmazione che possono preoccuparsi degli effetti che devono essere vietati. (Allora devi essere tu a scrivere i programmi; non sono più scatole nere.) Per citarne uno, usare un linguaggio di programmazione puro (che ti costringerebbe a programmare senza effetti collaterali) come Haskell farà semplicemente tutti gli effetti del programma esplicito, in modo che il programmatore possa facilmente assicurarsi che non vi siano effetti non consentiti.
Immagino che ci siano servizi di sandboxing disponibili per coloro che programmano in qualche altra lingua, ad esempio Java.
Alcune pagine che accumulano informazioni su questo argomento sono state anche indicate nelle risposte lì: