Non penso che ci sia modo di, in generale, garantire che un programma casuale non scriva nulla da nessuna parte. Stai cercando qualcosa di simile per risolvere il problema di arresto , con una svolta (anche stdout e stderr sono esposti come handle di file).
Tuttavia, è possibile creare una piccola libreria che sostituisce la manciata rilevante di chiamate di libreria standard, come creat (2), open (2), write (2) e alcuni altri, per non persistere nulla sul disco. Questo sarebbe probabilmente qualcosa di simile al libfaketime e dovrebbe essere ragionevolmente fattibile. Sarebbe portabile a qualsiasi applicazione tramite il meccanismo di precarico della libreria LD_PRELOAD del caricatore dinamico.
Tuttavia, quasi sicuramente non sarebbe una soluzione completa. Soprattutto un processo che funziona come root potrebbe facilmente annullare tutto ciò, se sa aspettarselo e vuole fare del male. Per prima cosa, dipende dal fatto che tali chiamate passino attraverso le interfacce comuni come la libreria C, che non è garantita; un processo potrebbe altrettanto facilmente copiare il codice della libreria C direttamente nel proprio codice. Potrebbe effettuare chiamate dirette alle interfacce syscall del kernel. La libreria C non è qualcosa di magico; è il codice userpace come un altro. E il binario potrebbe essere staticamente collegato, nel qual caso il caricatore dinamico non verrà affatto richiamato. Probabilmente è possibile aggirare queste limitazioni e prevenire le scritture, ma ...
È molto probabile che fare write (2) e gli amici no-ops rompa le cose a qualche altra estremità, quando il processo prevede che un file in cui è stato scritto contenga i dati che sono stati scritti.
E se non scrivesse davvero nulla, ma leggesse semplicemente un paio di file di configurazione critici per la sicurezza (/ etc / crypttab, / etc / shadow, /etc/bind/rndc.key, ... hai l'idea) e passa quei dati da qualche altra parte; sulla rete, forse, o la scarica in modo che diventi accessibile attraverso un attacco del canale laterale?
Farei un passo oltre il savanto . La prassi di sicurezza standard dovrebbe consistere nel non eseguire software non attendibile, punto. E sicuramente non dovresti eseguire software non attendibile come root. Per tutto ciò che funziona come root, puoi mettere un paio di blocchi stradali, ma non puoi garantire che non farà tutto ciò che vuole fare. SELinux può aiutare, e probabilmente va molto lontano se usato correttamente, ma è una bestia da configurare e probabilmente farà sì che eventuali violazioni delle politiche portino al fallimento della chiamata in questione con una condizione di errore e probabilmente un'interruzione del processo difficile, quindi ha vinto essere grazioso a tutti.
Il più vicino a ciò che sembra voler fare a cui riesco a pensare, che funzionerà nel caso generale, sarebbe una macchina virtuale isolata con la capacità di eseguire il rollback delle modifiche apportate al disco (di solito indicato come capacità di rollback dell'istantanea) . Ciò, tuttavia, sarà tutt'altro che semplice e comporterà un notevole sovraccarico poiché sei a tutti gli effetti in esecuzione una seconda istanza del sistema operativo, con tutto ciò che ciò significa.