Quanto è utile il montaggio / tmp noexec?

Molte persone (incluso il Manuale di protezione di Debian ) raccomandano il montaggio /tmpcon il noexec,nodev,nosuidset di opzioni. Questo è generalmente presentato come un elemento di una strategia di "difesa in profondità", impedendo l'escalation di un attacco che consente a qualcuno di scrivere un file o un attacco da parte di un utente con un account legittimo ma senza altro spazio scrivibile.

Con il passare del tempo, tuttavia, ho incontrato argomenti (in particolare lo sviluppatore Debian / Ubuntu Colin Watson) che noexecè una misura inutile, per un paio di potenziali motivi:

1. L'utente può eseguire /lib/ld-linux.so <binary>nel tentativo di ottenere lo stesso effetto.
2. L'utente può comunque eseguire interpreti forniti dal sistema su script che non possono essere eseguiti direttamente

Alla luce di questi argomenti, la potenziale necessità di una maggiore configurazione (ad es. Come debconfuna directory temporanea eseguibile) e la potenziale perdita di convenienza, è una valida misura di sicurezza? Quali altri buchi conosci che consentono l'elusione?

Ecco gli argomenti per l'utilità che ho escogitato finora:

I kernel moderni risolvono il problema /lib/ld-linux.so, in modo che non sia in grado di mappare le pagine eseguibili da un noexecfilesystem.

Il punto degli interpreti è sicuramente ancora una preoccupazione, anche se penso che meno di quanto la gente possa affermare. Il ragionamento che mi viene in mente è che ci sono state numerose vulnerabilità legate all'escalation dei privilegi che si basavano sulla realizzazione di syscall particolari malformati. Senza un attaccante che fornisce un binario, sarebbe molto più difficile creare malvagi syscalls. Inoltre, gli interpreti di script dovrebbero essere privi di privilegi (so che a volte questo non è stato il caso, come nel caso di un suid perl), e quindi avrebbero bisogno della propria vulnerabilità per essere utili in un attacco. Apparentemente, è possibile usare Python, almeno, per eseguire alcuni exploit.

Molti exploit "in scatola" possono tentare di scrivere ed eseguire eseguibili /tmp, noexecriducendo così la probabilità di cadere in un attacco tramite script (ad esempio nella finestra tra la divulgazione della vulnerabilità e l'installazione della patch).

Quindi, c'è ancora una prestazione di sicurezza per il montaggio /tmpcon noexec.

Come descritto nel bug tracker di Debian , l'impostazione APT::ExtractTemplates::TempDirin apt.confuna directory che non è noexecaccessibile a root eliminerebbe la preoccupazione di debconf.

Molti pacchetti Debian richiedono che / tmp sia eseguibile per l'installazione del pacchetto. Questi sono spesso contrassegnati come bug (di gravità 'normale' / 'lista dei desideri'):

https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp

Ho ricevuto proprio questo errore durante l'installazione di un kernel aggiornato sul ramo stabile proprio oggi.

Quindi sembra che Debian (& derivati?) Non sia pronto per il montaggio di / tmp noexec ...

aggiungere 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";};

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 / tmp noexec o l'esecuzione di SSH su una porta alternativa) contrasteranno gli attacchi automatici o basati su script che si basano sulle impostazioni predefinite in ordine funzionare. Non ti proteggerà da un aggressore determinato e ben informato, ma ben oltre il 99% delle volte, non dovrai affrontare un attaccante determinato o ben informato. Invece, ti difenderai da uno script di attacco automatico.

Primo: copre molti, diversi casi di attacco. Disattivarlo perché c'erano alcuni modi noti intorno (alcuni dei quali addirittura risolti) è strano. Gli attaccanti che scaricano codice su / dev / shm o / tmp sono una cosa comune che fanno.

La difesa in profondità riguarda la protezione dei waypoint più comuni, ognuno che li blocca rende il sistema più sopravvissibile. Non sicuro. Ma avrà anche una possibilità . Se non riescono a recuperare il loro payload secondario, è una buona possibilità che tu lo stia ottenendo.

• Potrebbe anche essere bloccato da restrizioni dell'utente iptables.
• Potrebbe anche essere interrotto da SELinux.
• Potrebbe anche non essere arrestato a causa di un altro exploit facilmente accessibile.

Il punto è quello di rendere così difficile come si facilmente possibile, e tagliare fuori il 99% degli attacchi.

Secondo: interrompe le cattive pratiche (eseguendo roba da temp, eseguendo importanti installazioni di applicazioni tramite / tmp anziché un utente tmpdir), lasciando i dati in / tmp. I programmi di installazione personalizzati di solito comprendono TMPDIR Inoltre: anche in caso contrario: il tempo di installazione, come azione temporizzata, non è un motivo valido per disattivare definitivamente un problema di sicurezza .

Terzo: considerando gli spazi dei nomi anonimi in / tmp (una "caratteristica"), si vuole davvero limitare ciò che viene inserito ed eseguire da lì.

Forth: la convenienza non è un fattore rilevante in questo. Supponendo che gestiamo server per denaro e per uno scopo: siamo responsabili di queste cose. "Oh, non ho bloccato / tmp perché allora ho bisogno di qualche minuto in più quando aggiorno il mio software l'anno prossimo". Sicuramente non sarà solo questa cosa che si frappone tra essere ricattato e stare bene. Una grande ragione? Io non la penso così.

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 armi ai nostri soldati."

Aspetta cosa?

Esistono altre misure che richiedono molti più sforzi, esperienza e fortuna per proteggere un sistema e conoscere le persone che hanno denaro, durata della vita limitati e vorrebbero anche trascorrere del tempo con le loro famiglie: non saltare le cose facili.

Ci sono applicazioni che richiedono / tmp per essere eseguibile per l'installazione. In un precedente lavoro, prima di arrivare lì, gli amministratori avevano impostato / tmp noexec, ma ho scoperto che il pacchetto db2 non si sarebbe installato. Anche se si annulla l'avvio del pacchetto db2 da qualche altra parte, la procedura di installazione copia alcuni file in / tmp e prevede di essere in grado di eseguirlo, il che ovviamente non è riuscito con il permesso negato. Se non sei consapevole del fatto che il filesystem sia montato su noexec, potrebbe essere un po 'fuorviante. È stato in grado di continuare l'installazione solo dopo aver rimontato / tmp senza noexec.

Ad ogni modo, il punto è che almeno un prodotto commerciale richiede / tmp per non essere montato su noexec e potrebbero essercene altri. Non ho trovato un motivo davvero convincente per questo. Se vuoi una maggiore sicurezza, preferirei scegliere Selinux.