Il existe un moyen encore plus simple de contourner l'autorisation "exécuter": copiez le programme dans un répertoire que vous possédez et définissez le bit "exécuter".

La permission "exécuter" n'est pas une mesure de sécurité . La sécurité est fournie à un niveau inférieur, le système d'exploitation limitant des actions spécifiques. Ceci est fait parce que, sur de nombreux systèmes de type Unix (en particulier à l'époque de Ritchie et Thompson), on suppose que l'utilisateur est capable de créer ses propres programmes. Dans une telle situation, utiliser la permission "exécuter" comme mesure de sécurité est inutile, car l'utilisateur peut simplement créer sa propre copie d'un programme sensible.

À titre d'exemple concret, exécuter fdisk en tant qu'utilisateur non privilégié pour essayer de brouiller la table de partition du disque dur:

  $ / sbin / fdisk / dev / sda Bienvenue dans fdisk (util-linux 2.24.1). Ne restez en mémoire que jusqu'à ce que vous décidiez de les écrire.Faites attention avant d'utiliser la commande d'écriture .... Changement du type de partition 'Linux' en 'Hidden NTFS WinRE'.Commande (m pour l'aide): wfdisk: échec d'écriture de disklabel : Mauvais descripteur de fichier  

Cette dernière ligne est fdisk essayant d'obtenir un descripteur de fichier "écriture" pour le disque dur et échoue, car l'utilisateur que j'exécute il n'a pas la permission de faire cela.

Le but de la permission "exécuter" est double: 1) pour dire au système d'exploitation quels fichiers sont des programmes, et 2) pour dire à l'utilisateur quels programmes ils peuvent exécuter. Ces deux éléments sont plus consultatifs qu'obligatoires: vous pouvez créer un système d'exploitation parfaitement fonctionnel sans autorisation, mais cela améliore l'expérience utilisateur.

Comme R .. le souligne, il existe un cas particulier où le "execute "l'autorisation est utilisée pour la sécurité: lorsqu'un programme a également le bit" setuid "défini. Dans ce cas, l'autorisation «exécuter» peut être utilisée pour restreindre les personnes autorisées à exécuter le programme. Toute méthode de contournement de l'autorisation "execute" supprimera également le statut "setuid", il n'y a donc aucun risque de sécurité ici.

Vous pouvez définir le bit d'exécution, mais pas le bit de lecture, sur un fichier exécutable. De cette façon, personne ne pourra copier le fichier, mais les gens peuvent quand même l'exécuter.

C'est assez inutile aujourd'hui, car a) cela fonctionne uniquement pour les programmes compilés, pas avec des scripts (sur la plupart des systèmes) ; b) ces jours-ci, 90% de tous les Unix étant Linux, les gens peuvent copier des exécutables à peu près n'importe où, et c) l'espace disque occupé par un exécutable copié n'a pas vraiment d'importance.

Pourtant, il y avait utilise pour cela dans l'ancien temps.

Le système Unix que j'utilisais à l'école, il y a 30 ans, était très limité en RAM et en espace disque. Surtout, le système de fichiers / usr / tmp était très petit, ce qui posait des problèmes lorsque quelqu'un essayait de compiler un gros programme. Bien sûr, les étudiants n'étaient pas censés écrire de «grands programmes» de toute façon; les grands programmes étaient généralement des codes source copiés «quelque part». Beaucoup d'entre nous ont copié / usr / bin / cc dans / home / <myname> / cc , et utilisé dd pour patcher le binaire afin d'utiliser / tmp au lieu de / usr / tmp , qui était plus gros. Bien sûr, cela n'a fait qu'aggraver le problème - l'espace disque occupé par ces copies importait à l'époque, et maintenant / tmp se remplissait régulièrement, empêchant même les autres utilisateurs de modifier leurs fichiers. Après avoir découvert ce qui s'était passé, les administrateurs système ont fait un chmod go-r / bin / * / usr / bin / * qui a "résolu" le problème et supprimé toutes nos copies du compilateur C.

Une autre utilisation est d'indiquer au shell quels fichiers sont destinés à être exécutés et lesquels ne le sont pas. Vous ne voulez pas qu'un fichier texte aléatoire soit exécuté parce que vous avez tapé son nom; le bit x fournit un moyen d'éviter cela. (De nos jours, le shell pouvait simplement regarder le début du fichier, et ne l'exécuter que s'il commence par #! , mais cela a été introduit beaucoup plus tard). La fonction de complétion de bash , également, suggérera des fichiers avec des bits exécutables uniquement lorsque vous tapez une commande.

Il existe une manière toute faite d'exécuter un fichier arbitraire: passez-le comme argument à l'éditeur de liens dynamique (qui est l'interpréteur approprié pour un exécutable chargé dynamiquement). Par exemple. sous Linux,

  cp / bin / ls / tmp / chmod -x /tmp/ls/lib/ld-linux.so.2 / tmp / ls  

Cependant, cela vient avec la même restriction que la lecture du fichier et le passage au code: les bits setuid ne sont pas évalués.

Dans l'ancien temps, nous avions souvent ont des binaires comme /bin/su:

  -rwsr-xr-- root wheel ... / bin / su  

Seuls les membres du groupe wheel , que les administrateurs système ont coupé aux personnes connaissant le mot de passe root pourraient même exécuter la commande su , donc même si un buffer overflow existait dans ce binaire, permettant aux appelants de contourner la sécurité, l'exploit ne serait utilisable que par des personnes qui connaissent le mot de passe de toute façon.

Je suis surpris que personne d'autre n'ait fait référence à une autre utilisation de + x bit: directory. Peut-être que vous êtes après l'exécution (exemple) de quelque chose dans / bin (script shell ou autre), mais il y a plus à exécuter des bits que des fichiers (bien sûr, un répertoire EST un fichier mais c'est un type de fichier différent).

Si vous avez un accès + x sur un répertoire mais -r sur ce même répertoire, alors vous aurez les capacités suivantes:

• Si vous connaissez le nom d'un fichier ( ou répertoire) dans ce répertoire, vous pouvez le lister (par exemple, ls dessus). Vous devez cependant connaître le nom.
• Vous ne pouvez pas le modifier (via la commande cd ou l'appel système chdir).

Si toutefois, vous avez -x et + r, vous pouvez faire ce qui suit:

• Vous ne pouvez pas accéder au répertoire (de la même manière que ci-dessus).
• Vous pouvez lister les fichiers. Mais comme vous n'avez pas accès + x au répertoire, vous ne pouvez pas accéder aux fichiers eux-mêmes.
• Cela signifie également que vous ne pouvez pas mettre à jour (horodatage uniquement ou autre) et vous ne pouvez pas non plus les ouvrir dans un éditeur de texte (ou cat, ou ...).

Si vous avez + rx alors vous pouvez faire tout cela (sauf que vous avez besoin de + w pour écrire dans le répertoire lui-même, c'est-à-dire créer de nouveaux fichiers; l'édition de fichiers fonctionne, la suppression ne fonctionne pas, la création ne fonctionne pas)

Et oui, cela signifie qu'il est possible que certaines personnes visualisent ou modifient des fichiers, mais seulement si elles connaissent le chemin exact de celui-ci ( tant qu'ils ont le droit de modifier, de toute façon). Et oui: ls est une liste et cela vaut pour la recherche de répertoires. Donc en résumé: exécuter un répertoire, c'est le changer (pour une raison quelconque). Bien sûr, ce qui compte vraiment, c'est ce qui compte vraiment.

Si, pour une raison quelconque, vous souhaitez garder le code binaire secret, vous pouvez rendre le programme exécutable sans être lisible. Cela n'est pas utile si ces utilisateurs ont un accès physique à la machine. Cela n'est pas non plus utile si le code source ou binaire est largement disponible. C'est donc un cas d'utilisation assez limité.

Si le programme a un bit setuid ou setgid, l'accès d'exécution fait quelque chose de plus que ce qui peut être réalisé en lisant le binaire. Une approche consiste à créer un exécutable setuid qui n'est exécutable que pour un groupe spécifique. S'il était lisible partout dans le monde, les personnes extérieures à ce groupe ne pouvaient toujours pas le copier et utiliser le bit setgid sur l'exécutable d'origine. (Bien que dans la plupart des cas, je préfère utiliser setgid plutôt que setuid, puis utiliser le groupe du répertoire pour contrôler qui peut accéder à l'exécutable.)

Habituellement, le bit exécutable est simplement utilisé pour indiquer quels fichiers sont des programmes en premier lieu. De cette façon, la complétion peut mieux fonctionner et vous n'exécutez pas les exécutables indésirables par accident.

Si vous voulez empêcher les utilisateurs de copier un exécutable et de l'exécuter, vous pouvez monter des répertoires personnels avec noexec . Pour que cela ait un sens, vous devez utiliser noexec pour chaque système de fichiers, où l'utilisateur peut écrire n'importe quoi.

L'autorisation d'exécution du bit est vérifiée par le noyau lors de l'exécution de l'appel système exec (2) (et ses cousins). Vous n'en aurez besoin que pour exécuter des programmes au niveau du noyau.

Seuls les programmes avec ce bit activé (quel que soit le résultat qui vous est attribué en tant que propriétaire, groupe ou autre est ce qui est vérifié) peuvent être exec () ed par le noyau.

Une autre chose différente est ce que fait le shell lors de l'interprétation d'un script shell ou perl, ou quel que soit l'interpréteur que vous avez. Sur les scripts, le noyau vérifie le #! ... au début du fichier comme un nombre magique, et lance le shell indiqué ici (vous aurez également besoin d'une autorisation d'exécution pour le shell), et vous ont besoin des autorisations de lecture sur ce script, car le shell doit l'ouvrir et le lire pour être interprété. Pour les scripts shell, vous aurez besoin d'une autorisation de lecture ainsi que d'une autorisation d'exécution. Mais pour les scripts shell, vous avez uniquement besoin d'une autorisation de lecture, car vous pouvez toujours exécuter un script shell en exécutant le shell et en passant le script shell en tant que paramètre (ou fichier d'entrée )

Bien sûr, comme cela a été indiqué, le bit d'exécution peut être contourné en copiant le programme et en le rendant exécutable, mais vous ne pourrez pas le copier si vous n'avez pas lu autorisations pour faire cette copie (vous continuez à pouvoir l'exécuter).

Essayez de changer (en tant que root bien sûr) les autorisations en ls (1) et faites-en 0111 ( --- x - x - x ) et essayez d'en faire une copie exécutable, et voyez comment vous ne pouvez pas obtenir votre copie exécutable, même si vous continuez à pouvoir l'exécuter.

Sur les répertoires, exécuter bit signifie une chose différente. Le noyau utilise l'autorisation ' x ' lors de l'itération dans le chemin (dans la fonction noyau namei () ) donc si vous n'avez pas les autorisations d'exécution sur un répertoire, vous ne soit l'utiliser, ni les fichiers accessibles par son intermédiaire. Même vous pouvez lire le contenu d'un répertoire avec des autorisations de lecture, mais vous ne pouvez pas accéder aux fichiers qu'il contient. Ou au contraire, vous pouvez avoir des autorisations d'exécution sur un répertoire mais pas un accès en lecture, et vous pourrez utiliser les fichiers à l'intérieur, mais vous ne pourrez pas voir le contenu du répertoire.