Verfication des binarys de command avant l'exécution

Existe-t-il des methods pour vérifier ce que vous exécutez réellement à partir d'un script bash?

Supposons que votre script bash appelle plusieurs commands (par exemple: tar , mail , scp , mysqldump ) et que vous êtes prêt à vous assurer que tar est le tar réel, qui peut être déterminé par l'user root qui est le propriétaire du directory parent et le seul avec des permissions d'écriture et non un peu /tmp/surprise/tar avec www-data ou apache2 étant le propriétaire.

Bien sûr, je connais PATH et l'environnement, je suis curieux de savoir si cela peut être en outre vérifié à partir d'un script bash en cours d'exécution et, si oui, comment exactement?

Exemple: (pseudo-code)

 tarfile=$(which tar) isroot=$(ls -l "$tarfile") | grep "root root" #and so on... 

Au lieu de valider les binarys que vous allez exécuter, vous pouvez exécuter les binarys adéquats dès le début. Par exemple, si vous voulez vous assurer de ne pas exécuter /tmp/surprise/tar , exécutez /usr/bin/tar dans votre script. Sinon, définissez votre $PATH sur une valeur saine avant de lancer quoi que ce soit.

Si vous ne faites pas confiance aux files dans /usr/bin/ et d'autres directorys système, il n'y a aucun moyen de regagner la confiance. Dans votre exemple, vous vérifiez le propriétaire avec ls , mais comment savez-vous que vous pouvez faire confiance à ls ? Le même argument s'applique à d'autres solutions telles que md5sum et strace .

Lorsqu'une grande confiance dans l'intégrité du système est requirejse, des solutions spécialisées comme l' IMA sont utilisées. Mais ce n'est pas quelque chose que vous pouvez utiliser à partir d'un script: tout le système doit être configuré de manière particulière, avec le concept de files immuables en place.

Si un intrus a accédé à votre système et est capable de modifier votre $PATH (qui ne doit pas inclure /tmp en aucun cas), il est trop tard pour commencer à s'inquiéter de la propriété des exécutables.

Au lieu de cela, vous devriez lire comment faire face à une intrusion .

Mieux vaut se concentrer sur l'évitement de l'intrusion.

Si vous avez un système où ces choses sont importantes, il peut être judicieux d'isoler les parties qui doivent être publiques des parties qui doivent être privées, ainsi que d'effectuer un audit des modes de communication entre ceux-ci.

Il est possible dans une certaine mesure en vérifiant le md5sum d'un file. Ainsi, sur les systèmes qui utilisent apt package management – dans mon cas particulier, Ubuntu 16.04 – il y a le file /var/lib/dpkg/info/tar.md5sums qui stocke les sums md5 de tous les files provenant de tar lors de l'installation. Vous pouvez donc écrire une instruction if simple qui vérifie si la sortie de md5sum /bin/tar correspond à ce qui se trouve dans ce file.

Cela suppose bien sûr que le file lui-même n'a pas été falsifié. Bien entendu, cela ne peut se produire que lorsque l'attaquant a access root / sudo, auquel cas tous les paris sont désactivés.

Oui, il existe une méthode: le type embedded. type vous dira si le nom de la command est en fait un mot-key réservé, un builtin, un alias, une fonction ou un file disque.

 $ type -t foobar || echo "Not found" Not found $ type -t echo builtin $ enable -n echo; type -t echo; type -p echo file /usr/bin/echo $ echo() { printf "(echoing) %s\n" "$*"; }; type -t echo function $ alias echo="/bin/echo 'I say: ' "; type -t echo alias 

De plus, le type -a vous donnera tous les candidats pour votre command (du premier au dernier choix):

 $ type -a echo echo is aliased to `/bin/echo 'I say: ' ' echo is a function echo () { printf "(echoing) %s\n" "$*" } echo is a shell builtin echo is /usr/local/bin/echo echo is /bin/echo 

Enfin, si vous ne vous préoccupez que des binarys sur votre disque, vous pouvez utiliser le type -Pa pour get tous les binarys de votre PATH (dans le même ordre que ci-dessus):

 $ type -Pa tar /home/me/bin/tar <= oh oh, is this normal? /bin/tar 

Cela dit, type seul ne vous dira pas exactement quelle command sera appelée à la fin. Par exemple, si votre tar est un alias qui appelle un binary (par exemple, alias tar="/tmp/tar" ) alors type vous dira qu'il s'agit d'un alias .

Vous pouvez vérifier quelles commands sont exactement exécutées par un script en utilisant strace . Par exemple:

 strace -f -e execve ./script.sh 

Avec le script suivant:

 #!/bin/bash touch testfile.txt echo "Hello" >> testfile.txt cat testfile.txt rm testfile.txt 

strace vous indiquera le path exact vers les commands exécutées avec le paramètre -e execve :

 execve("./script.sh", ["./script.sh"], [/* 69 vars */]) = 0 Process 8524 attached [pid 8524] execve("/usr/bin/touch", ["touch", "testfile.txt"], [/* 68 vars */]) = 0 [pid 8524] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8524, si_status=0, si_utime=0, si_stime=0} --- Process 8525 attached [pid > 8525] execve("/bin/cat", ["cat", "testfile.txt"], [/* 68 vars */]) = 0 Hello [pid 8525] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8525, si_status=0, si_utime=0, si_stime=0} --- Process 8526 attached [pid > 8526] execve("/bin/rm", ["rm", "testfile.txt"], [/* 68 vars */]) = 0 [pid 8526] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8526, si_status=0, si_utime=0, si_stime=0} --- +++ exited with 0 +++ 

Paramètres (de strace man):

-f : Trace les process enfants tels qu'ils sont créés par les process tracés en cours à la suite des appels système fork (2), vfork (2) et clone (2). Notez que -p PID -f attachera tous les threads du process PID s'il est multi-thread, pas seulement thread avec thread_id = PID.

-e trace=file : Trace tous les appels système qui prennent un nom de file comme argument. Vous pouvez considérer cela comme l'abréviation de -e trace=open,stat,chmod,unlink,... ce qui est utile pour voir les files auxquels le process fait reference. En outre, l'utilisation de l'abréviation vous évitera d'oublier un appel comme lstat dans la list.

Linux os est basé sur des files et de nombreuses commands exécutées sur Linux vont probablement résoudre certaines modifications dans les files situés sur votre machine. C'est peut – être la meilleure solution pour votre problème. Vous pouvez tester vos commands pour toutes les modifications sur le système de files avant qu'il ne soit exécuté.

entrer la description de l'image ici

Il y a la command 'strace' qui décomstack votre command en parties …

entrer la description de l'image ici

Si vous voulez vraiment aller profondément, vous voulez vérifier les décompilateurs pour les scripts que son va être exécuté. En d'autres termes, vous devez vérifier l'interprétation de l'assembleur de cette command. Pour bash là objdump -d . Les scripts bin de Linux sont principalement créés avec le C programmation C , donc utilisez un bon décompilateur C