Bonjour, merci d’avance pour vos réponse. Je cherche à monter un disque réseau cifs et j’ai remarque que la commande mount aime bien qu’on soit le plus précis possible. C’est un disque contenant de la data donc à interdire en exécution et en écriture, aussi j’ai configuré file_mode=0444. En lisant la doc j’ai vu l’option « noexec » qui interdit aussi l’exécution des fichiers binaires sur le disque.
Quelle est la différence entre un masque 0444 et « noexec » ?
Merci d’avoir lu ce poste
1 J'aime
Bonjour,
Si je comprends bien le manuel de mount, l’option noexec est l’option qui doit être disponible sur tous les systèmes de fichiers montables avec la commande mount.
FILESYSTEM-INDEPENDENT MOUNT OPTIONS
[…]
noexec Do not permit direct execution of any binaries on the mounted filesystem.
L’option file_mode, quant à elle, n’est pas dans les options génériques, c’est propres aux systèmes de fichiers qui ne gèrent pas les droits d’accès, comme cifs et vfat, par exemple.
1 J'aime
Salut Almtesh, je te remercie vivement pour ta réponse claire et rapide et l’intérêt que tu as porté à ma question. Ok je comprends la différence maintenant, « noexec » est une option de mount qui fonctionne pour tout les systèmes de fichier tandis que File_mode est spécifique au système cifs. Par contre je ne comprends pas si les options se « chevauchent », en d’autres termes, si j’ai déjà attribué un file_mode=0222 par exemple, qui interdit l’exécution au niveau des droits, est-ce utile de spécifier en plus l’option « noexec » ?
1 J'aime
À titre personnel, je te recommande de n’utiliser qu’une seule des deux options à la fois.
En général, il vaut mieux éviter de « surdéfinir » un comportement, la duplication est à éviter au maximum, tu peux te retrouver avec un comportement innatendu en cas de modification ultérieure.
Je te conseille aussi de faire au plus simple, si tu ne veux qu’empêcher l’exécution, préfère l’option noexec.
1 J'aime
Bonsoir,
Almtesh a raison, mount n’a pour but que de qualifier les droits et options à minima, pas à maxima. c’est ensuite au niveau des droits sur les fichiers que le detail se fera.
1 J'aime
Merci pour ces réponses claires.
1 J'aime
@Zargos : Je ne comprends pas ta réponse. Ces deux options ne font pas la même chose.
« file_mode » définit le « mode » (bits de « permission » Unix) apparent des fichiers, qui n’est qu’un élément parmi d’autres affectant les permissions effectives (l’option de montage « noexec » ou les ACL POSIX en sont d’autres). Ne pas oublier non plus que « file_mode » définit le mode visible de tous les fichiers du montage CIFS et est transféré lors de la copie de ceux-ci. Il n’est pas forcément souhaitable que les fichiers de données apparaissent avec le bit exécutable. A noter que d’après la page de manuel de mount.cifs, l’option « file_mode » n’a d’effet que si le serveur CIFS ne supporte pas les extensions Unix.
Il m’apparaît donc souhaitable d’utiliser à la fois « noexec » pour interdire l’exécution et « file_mode » pour définir le mode visible des fichiers si le serveur ne supporte pas les extensions Unix.
3 J'aime
Pour compléter les explications de @PascalHambourg
Les options du type file_mode sont là pour les filesystems qui n’ont pas de possibilité d’avoir un système de droit « POSIX » user/group/other et RWX. Donc, on force des droits sur tout le système de fichier.
Par contre, l’option no_exec est plus là pour protéger votre système. Par exemple, je monte souvent mes /tmp, /home etc avec cette option. Cela permet de protéger votre système contre certaines attaques. On vous pose un binaire malveillant, puis on l’exécute. Bon, je mets de moins en moins cette option (cloud toussa). Et c’est relativement simple à contourner pour un attaquant « sérieux ».
Mes 2 ¢
1 J'aime
effectivement c’est pas mal utilisé dans cette optique là; sachant que la sécurité d’un système ne dépend d’une application qui fait tout, mais de plein de petites actions, paramétrages qui permettent pas leur somme de contrer un certain nombre d’attaque ou de les ralentir. sachant que dans le pirate le temps est l’ennemi de la réussite
1 J'aime
Il faudrait surtout préciser que l’absence du bit d’exécution sur un fichier n’empêche en rien son exécution par un utilisateur qui à les droits en lecture.
1 J'aime
Par exemple dans le cas d’un script en le lançant via l’interpréteur :
python /tmp/machin-pas-exécutable.py
Ou simplement en copiant le fichier dans un autre chemin qui ne soit pas monté avec noexec :
cp /tmp/machin-pas-exécutable.py ~/bin/
chmod +x ~/bin/machin-pas-exécutable.py
~/bin/machin-pas-exécutable.py
Je n’ai pas testé, mais je me demande si le built-in shell exec ne peut pas aussi être utilisé pour contourner un montage en noexec :
exec /tmp/machin-pas-exécutable.py
Effectivement il suffit de connaître l’interpréteur à utiliser. Pour les fichiers en langage interprété (bash, python, php, etc.) c’est trivial.
Autre exemple avec un binaire ELF :
$ sudo chmod -x /bin/ls
Je retire le bit d’exécution de la commande ls, conséquence :
$ ls
bash: /bin/ls: Permission non accordée
Je regarde de quel type de fichier il s’agit :
$ file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=2f15ad836be3339dec0e2e6a3c637e08e48aacbd, for GNU/Linux 3.2.0, stripped
Je connais maintenant l’interpréteur à utiliser :
$ /lib64/ld-linux-x86-64.so.2 /bin/ls /
bin cdrom dev home lib lib64 media opt root sbin sys usr vmlinuz
On peut dire que le bit d’exécution sur les fichiers n’est là que pour des raisons de commodité. Par contre sur les dossiers son absence empêche d’y accéder.
Remarque : le exec du shell remplace le shell courant par la commande spécifiée, ce n’est donc pas utilisable pour cela. cf help exec
2 J'aime