Un bref message d'avertissement sur la sécurité des scripts est approprié. Un script shell peut contenir un ver (worm), un troyen (trojan) ou même un virus. Pour cette raison, ne lancez jamais un script en tant que root (ou ne permettez jamais son insertion dans les scripts de démarrage du système /etc/rc.d) à moins que vous n'ayez obtenu ledit script d'une source de confiance ou que vous l'ayez consenscieusement analysé pour vous assurer qu'il ne fait rien de nuisible.
De nombreux chercheurs chez Bell Labs et d'autres sites, incluant M. Douglas McIlroy, Tom Duff et Fred Cohen ont étudié les implications des virus de scripts shell. Ils concluent qu'il est tout à fait facile même pour un novice, un « script kiddie », d'en écrire un. [91]
Voici encore une autre raison d'apprendre les scripts. Être capable de regarder et de comprendre les scripts peut protéger votre système d'être piraté ou endommagé.
Pour des raisons de sécurité, il pourrait être nécessaire de rendre un script illisible. Si seulement il existait un outil pour créer un binaire exécutable à partir d'un script. shc -- le compilateur générique de scripts shell de Francisco Rosales fait exactement cela.
Malheureusement, d'après un article dans le numéro d'octobre 2005 du Linux Journal, le binaire peut, au moins dans certains cas, être décrypté pour retrouver le source original du script. Malgré tout, cette méthode pourrait être utile pour conserver une certaine sécurité dans les scripts.
Dan Stromberg suggère les lignes de conduite suivante pour écrire des scripts shell (relativement) sécurisés.
Ne placez pas des données privées dans des variables d'environnement.
Ne passez pas des données privées en arguments de commandes external externes (à la place, utilisez un tube ou une redirection).
Configurez votre $PATH avec attention. Ne faites pas confiance aux chemins dont vous héritez par l'appelant sur votre script fonctionne en tant qu'utilisateur root. En fait, à chaque fois que vous utilisez une variable d'environnement héritée d'un appelant, pensez à ce qui peut arriver dans le cas où l'appelant a modifié la variable. Par exemple, l'appelant peut avoir modifié la valeur de $HOME avec /etc.
[91] Voir l'article de Marius van Oers, UNIX Shell Scripting Malware, et aussi la référence Denning dans la bibliographie.