Soluzione 1:
Ecco gli argomenti a favore dell'utilità che ho trovato finora:
I kernel moderni correggono il /lib/ld-linux.so hole, in modo che non sia in grado di mappare le pagine eseguibili da un noexec filesystem.
Il punto dell'interprete è certamente ancora una preoccupazione, anche se penso meno di quanto la gente potrebbe affermare. Il ragionamento che posso formulare è che ci sono state numerose vulnerabilità di escalation dei privilegi che si basavano sull'esecuzione di particolari chiamate di sistema malformate. Senza un utente malintenzionato che fornisca un binario, sarebbe molto più difficile effettuare chiamate di sistema malvagie. Inoltre, gli interpreti di script dovrebbero essere privi di privilegi (so che storicamente a volte non è stato così, come con un suid perl), e quindi avrebbero bisogno della loro stessa vulnerabilità per essere utili in un attacco. Apparentemente, è possibile utilizzare Python, almeno, per eseguire alcuni exploit.
Molti exploit "preconfezionati" potrebbero tentare di scrivere ed eseguire eseguibili in /tmp , e così noexec riduce la probabilità di subire un attacco con script (diciamo nella finestra tra la divulgazione della vulnerabilità e l'installazione della patch).
Pertanto, c'è ancora un vantaggio in termini di sicurezza nel montare /tmp con noexec .
Come descritto nel bug tracker di Debian, impostando APT::ExtractTemplates::TempDir in apt.conf in una directory diversa da noexec e accessibile a root eliminerebbe il problema di debconf.
Soluzione 2:
Molti pacchetti Debian richiedono che /tmp sia eseguibile affinché il pacchetto possa essere installato. Questi sono spesso contrassegnati come bug (di gravità 'normale'/'wishlist'):
https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp
Ho ricevuto solo questo errore durante l'installazione di un kernel aggiornato nel ramo stable proprio oggi.
Quindi sembra che Debian (e derivati?) non sia pronto per il montaggio di /tmp noexec...
Soluzione 3:
aggiungi quanto segue a /etc/apt.conf, o, /etc/apt/apt.conf.d/50remount
DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
Soluzione 4:
Anche se esistono soluzioni alternative per la maggior parte delle misure di sicurezza supplementari che potresti scegliere di implementare, anche le misure di sicurezza più facilmente aggirabili (come il montaggio di /tmp noexec o l'esecuzione di SSH su una porta alternativa) contrasteranno gli attacchi automatizzati o basati su script che si basano sulle impostazioni predefinite nell'ordine funzionare. Non ti proteggerà da un aggressore determinato e ben informato, ma ben oltre il 99% delle volte non ti troverai di fronte a un aggressore determinato o ben informato. Invece, ti difenderai da uno script di attacco automatico.
Soluzione 5:
Primo: Copre molti e diversi casi di attacco. Disattivarlo perché c'erano alcuni modi noti per aggirarlo (alcuni dei quali addirittura risolti) è strano. Attaccanti che scaricano codice su /dev/shm o /tmp è una cosa comune che fanno.
La difesa in profondità riguarda la protezione dei waypoint più comuni, ognuno che li ferma rende il tuo sistema più resistente. Non sicuro. Ma avrà anche una possibilità . Se non riescono a recuperare il loro payload secondario, hai buone possibilità.
- Potrebbe anche essere bloccato dalle restrizioni utente di iptables.
- Potrebbe anche essere fermato da SELinux.
- Potrebbe anche non essere fermato a causa di un altro exploit di facile accesso.
Il punto è renderlo difficile quanto te facilmente possibile, e tagliare il 99% degli attacchi.
Secondo: Interrompe le cattive pratiche (eseguire cose da temp, eseguire installazioni di applicazioni importanti tramite /tmp invece di un utente tmpdir), lasciando i dati in /tmp .I programmi di installazione personalizzati di solito comprendono TMPDIR Inoltre:anche se no:il tempo di installazione, come azione temporizzata, non è un motivo valido per disattivare un problema di sicurezza permanentemente .
Terzo: Considerando gli spazi dei nomi anonimi in /tmp (una "caratteristica"), vuoi davvero limitare ciò che viene messo lì ed eseguire da lì.
Quarto: La convenienza non è un fattore rilevante in questo. Supponendo che gestiamo i server per denaro e per uno scopo:siamo responsabili di queste cose. "Oh, non ho bloccato il /tmp perché poi avrò bisogno di qualche minuto in più quando aggiornerò il mio software l'anno prossimo". Sicuramente non sarà solo questa cosa che si frappone tra l'essere ricattati e stare bene. Un ottimo motivo? Non credo.
Che ne dici di questo:
"Abbiamo imparato che i nemici possono attaccare senza preavviso. Potrebbero anche usare centinaia di spie per avvelenare il cibo. Quindi abbiamo smesso di distribuire fucili ai nostri soldati."
Aspetta, COSA?
Ci sono altre misure che richiedono molto più impegno, esperienza e fortuna per proteggere un sistema, e sapere che le persone hanno denaro limitato, durata della vita e vorrebbero anche trascorrere del tempo con le loro famiglie:Non saltare le cose facili.