Lo scambio può essere disabilitato a livello di applicazione?

Attualmente sto usando thunderbird con gnupg per leggere e-mail crittografate. Se capisco correttamente il comportamento dello scambio, le pagine di memoria contenenti le e-mail decrittografate potrebbero essere scambiate e lasciare tracce sul disco rigido che in teoria potrebbero essere recuperate in modo forense.

Sebbene sia certamente possibile utilizzare solo un file di scambio crittografato o disabilitare lo scambio a livello globale per la durata dell'utilizzo di file sensibili, influisce sulle prestazioni, potrebbe essere dimenticato e richiede privilegi di root.

È possibile contrassegnare determinati file o programmi in modo che non vengano scambiati? Anche senza accesso root? Si potrebbe scrivere un'applicazione che può essere distribuita a utenti tecnicamente ingenui e il cui contenuto di memoria non viene mai scambiato su disco?

Nei commenti, ho suggerito di creare un cgroup, impostare memory.swappinesssu zero (per ridurre al minimo lo scambio) ed eseguire l'applicazione all'interno di esso. Se lo facessi, la tua applicazione probabilmente non cambierebbe a meno che tu non stia eseguendo una memoria fisica così incredibilmente bassa che lo scambio di pagine con programmi in quel cgroup era l'unico modo per rendere disponibile sufficiente memoria fisica.

Per fare questo su RHEL 6.5:

• Assicurarsi che il libcgrouppacchetto sia installato. Questo ti dà accesso a strumenti come userspace cgcreatee cgexec.

• Avviare e abilitare il cgconfigservizio in modo che le modifiche alla configurazione del cgroup siano persistenti tra i riavvii. Su RHEL questo servizio dovrebbe anche montare i filesystem richiesti sotto l' /cgroupalbero.

• Crea il cgroup con cgcreate -g memory:thunderbird

• Impostare lo swappiness su zero in questo gruppo con cgset -r memory.swappiness=0 thunderbird

• Utilizzare cgsnapshot -s > /etc/cgconfig.confper salvare una configurazione permanente aggiornata per il cgconfigservizio (tutte le modifiche finora sono state modifiche di runtime. Probabilmente vorrai salvare il file di configurazione predefinito da qualche parte e dargli una volta prima di renderlo la configurazione permanente.

• Ora puoi usare cgexecper avviare le applicazioni desiderate all'interno del thunderbirdcgroup:

  [root @ xxx601 ~] # cgexec -g memory: thunderbird ls

  anaconda-ks.cfg a.out foreman.log index.html install.log install.log.syslog node.pp sleep sleep.c ssl-build stack test

  [root @ xxx601 ~] #

In thunderbirdrealtà non ho installato, altrimenti l'avrei fatto. Non sono sicuro del motivo per cui la formattazione di quanto sopra è incasinata.

• Un'alternativa cgexecsarebbe quella di avviare thunderbird e aggiungere il PID al tasksfile per l'applicazione. Per esempio:

  [root @ xxx601 ~] # cat / cgroup / memory / thunderbird / task

  [root @ xxx601 ~] # pidof httpd

  25926 10227 10226 10225 10163 10162 10161 10160 10159 10157 10156 10155 10152 10109

  [root @ xxx601 ~] # echo 25926> / cgroup / memory / thunderbird / task

  [root @ xxx601 ~] # cat / cgroup / memory / thunderbird / task

  25926

Ancora una volta, è da ricordare che questo non impedisce tecnicamente lo scambio ma, a parte la modifica dell'applicazione stessa, è probabilmente la soluzione migliore. Ho appena scoperto memory.memsw.limit_in_bytesche sembra che potrebbe essere un controllo più diretto sul forzare lì a non fare lo scambio, ma non ci ho giocato abbastanza per sentirmi a mio agio nel dire che risolve completamente il tuo problema. Detto questo, potrebbe essere qualcosa da considerare dopo questo.

La vera risposta sarebbe quella di avere le mlockinformazioni sensibili dell'applicazione per aggirare questo tipo di preoccupazione. Sono disposto a scommettere che un'applicazione come Thunderbird lo fa, ma non so abbastanza degli interni per commentarlo.

Le applicazioni possono bloccare la memoria in modo che non possa essere scambiata.

mlock, munlock, mlockall, munlockall - lock and unlock memory

Non conosco un modo per influenzare questo dall'esterno, comunque. L'applicazione dovrebbe essere scritta per usarla da sola. Con la posta è probabilmente particolarmente difficile poiché di solito coinvolge anche programmi esterni per la visualizzazione di allegati e simili.

Inoltre, anche con memlock c'è la possibilità che finisca sulla partizione di swap - quando si utilizza suspend su disco che scrive tutta la memoria su disco, indipendentemente da qualsiasi preferenza non swap.

È più semplice eseguire la crittografia completa del disco in primo luogo.

Sì, un'applicazione può impedire che parte della sua memoria venga scambiata, con la mlockchiamata di sistema. Tuttavia, questo non è davvero utile nel tuo caso.

I dati riservati non sono solo nella memoria dell'applicazione. Si finisce in file temporanei in vari luoghi ( /tmp, /var/spool, ecc). Thunderbird stesso sta visualizzando l'e-mail decrittografata, quindi dovresti bloccarlo anche nella RAM.

Se vuoi assicurarti che il tuo disco non contenga tracce di file riservati, devi crittografare il tuo swap e tutte le potenziali posizioni dei file temporanei (in particolare, /tmpse non è tmpfs, e la maggior parte /var, inoltre, nella tua home directory ovviamente).

L'impatto dello swap crittografato sulle prestazioni è piccolo o nullo. La crittografia è molto più veloce dell'I / O del disco.

Sto solo pensando se sarebbe meglio iniziare con la modifica della priorità del processo di applicazione, ad esempio con uno script di avvio che lo avvia con una priorità alta usando nicee renicee con la priorità di I / O che cambia con ionicee poi vedi cosa accade.

Puoi "applicare" l'applicazione al massimo livello di priorità, ad esempio in -20questo modo lasci ancora il sistema operativo per fare ciò che fa meglio prendendo la decisione su quando scambiare i processi dell'applicazione.

Ma altri hanno suggerito che se si desidera un maggiore controllo e granularità, è necessario iniziare a guardare cgroupse impostarememory.swappiness