Script e sicurezza della shell

Question

La Guida avanzata di Bash Scripting di TLDP afferma che gli script della shell non devono essere utilizzati per "situations where security is important, where you need to guarantee the integrity of your system and protect against intrusion, cracking, and vandalism".

Ciò che rende gli script di shell non idonei per un simile caso d'uso?

Answer 1

A causa della malleabilità della shell, è difficile verificare che un lo script di shell svolge la funzione prevista e solo che funziona di fronte all'ingresso contraddittorio. Il modo in cui si comporta la shell dipende dall'ambiente, oltre alle impostazioni delle sue numerose variabili di configurazione. Ogni riga di comando è soggetta a più livelli di espansione, valutazione e interpolazione. Alcuni costrutti shell vengono eseguiti nei sottoprocessi mentre le variabili contenute nel costrutto vengono espanse nel processo padre. Tutto ciò è contrario al principio KISS quando si progettano sistemi che potrebbero essere attaccati.

Answer 2

Probabilmente perché è solo facile rovinare. Se lo PATH non è impostato correttamente, lo script inizierà ad eseguire i comandi errati. Mettere uno spazio da qualche parte in una stringa potrebbe far sì che diventi in seguito due stringhe. Questi possono portare a falle di sicurezza sfruttabili. In breve: le shell ti danno alcune garanzie su come si comportano i tuoi script, ma sono troppo deboli o troppo complessi per una programmazione veramente sicura.

(A questo vorrei aggiungere che la programmazione sicuro è un'arte in sé, e strizzando è possibile in qualsiasi lingua.)

Answer 3

Non sarei d'accordo con questa affermazione, in quanto non c'è nulla sugli script che li rendono intrinsecamente insicuri. Gli script di Bash sono perfettamente sicuri se vengono seguite alcune semplici linee guida:

• Lo script contiene informazioni che altri non dovrebbero essere in grado di visualizzare? Se è così, assicurati che sia leggibile solo dal proprietario.
• Lo script dipende dai dati di input di someWherE? In tal caso, assicurarsi che i dati di input non possano essere contaminati in alcun modo o che i dati contaminati possano essere rilevati e scartati.
• È importante che gli altri provino a eseguire lo script ? Se è così, come per il primo punto, assicurarsi che nessuno possa eseguirlo e preferibilmente non leggerlo. chmod 0700 è generalmente una buona idea per gli script che eseguono funzioni di sistema.
• E i casi in cui ci si vuole uno script per avere un setuid (tramite il suo interprete) sono estremamente rare

I due punti che separano uno script da un programma compilato sarebbe che la fonte è visibile e che un interprete lo esegue. Finché l'interprete non è stato compromesso (come avere un bit setuid su di esso), staresti bene.

Quando si scrivono script per eseguire attività di sistema, errori di battitura e errori generici umani durante la scrittura rappresentano in qualche modo un potenziale errore di sicurezza, ma ciò si verifica anche con programmi compilati (e molte persone tendono a ignora il fatto che i programmi compilati possono anche essere smontati)

Vale la pena notare che nella maggior parte (se non tutti) i sapori di Linux, la maggior parte (se non tutti, in effetti, non può pensare a nessuno che non lo sia) i servizi sono avviati tramite shellscript.

Answer 4

• è più facile per i ragazzi cattivi per rendere il lavoro script di shell in modo diverso (interagisce molto con altri processi, percorso, funzioni di shell, prifile)
• è più difficile per i buoni ragazzi a che fare con dati sensibili (passando le password, ecc.)