Cette semaine et la semaine prochaine, on va voir les différents moyens qui existent pour qu’un utilisateur puisse agir au-delà de ses permissions propres. Je coupe en deux car c’est assez copieux et je ne veux pas faire un article trop long, on verra donc les SUID/SGID cette semaine et le sudo la semaine prochaine.
Si la possibilité d’outrepasser ses permissions propres existe et s’avère nécessaire à un moment ou à un autre lorsque vous développez ou paramétrez votre machine, il convient de bien comprendre comment cela fonctionne et surtout les implications en termes de sécurité.
En effet, des possibilités trop larges en terme de permissions étendues offrent un vecteur d’attaque sur votre machine connu sous le nom de privilege escalation (aussi appelé privesc) : concrètement, le hacker cherche d’abord un accès quelconque à votre machine (par exemple via un couple login/mdp qu’il a récupéré par un autre biais et que vous réutilisez sur votre serveur) puis, partant de là, essaie d’augmenter ses privilèges petit à petit jusqu’à avoir accès aux informations qui l’intéressent.
Root, le grand manitou
Sur les systèmes Linux, il existe toujours un compte nommé root, appelé super-utilisateur en français, qui a absolument tous les droits sur tout le système (ce qui inclut le droit de tout casser).

Pour des raisons évidentes, ce compte doit absolument être sécurisé le plus possible : pas question de réutiliser un mdp faible pour lui. Faites un effort s’il-vous-plait et générez un truc unique et bien badass.
Root est le Graal pour un hacker. Si on arrive à devenir root ou à usurper ses droits par un autre biais, tout est permis : récupérer des données, effacer un maximum des traces de notre passage, tout casser en partant, etc.
Délégation de droits
Il est d’usage de ne donner le mdp de root qu’à l’administrateur de la machine en question et donc de ne se servir de ce compte que très rarement et pour des tâches d’administration bien spécifique. Cela évite pas mal de soucis sur le long terme.
Néanmoins, il est bien souvent nécessaire pour les utilisateurs de la machine de devoir effectuer des actions qui nécessitent des droits qu’ils n’ont pas et appeler root – ou tout du moins un utilisateur qui dispose des droits en question – à la rescousse à chaque fois n’est pas forcément un idéal d’efficacité dans une équipe de développement.
Afin de pallier ce problème, on a plusieurs leviers à notre disposition. Nous en verrons deux dans cet article, et un troisième la semaine prochaine.
Utiliser des groupes
On l’a vu dans l’article introductif sur les permissions : chaque fichier dossier est la propriété d’un utilisateur et d’un groupe et les droits sur l’entité en question en découlent.
Si vous ne pouvez pas, pour des raisons de sécurité, donner des droits aux utilisateurs lambda sur l’entité qui vous intéresse, il est peut-être possible par contre de l’attribuer à un groupe qui contiendra les utilisateurs pertinents. Pour ce faire, rien de plus simple : je vous renvoie à l’article de la semaine dernière sur l’administration des groupes, des droits et de la propriété des entités.
Bon en même temps quand je vous dis ça, je suis un peu en train de vous douiller parce que ceux qui ont lu l’article de la semaine dernière (et qui s’en souviennent) ont en tête que j’ai utilisé plusieurs fois le mot clé sudo dans mes commandes et que je l’avais mis de côté sans trop en parler. Sudo est justement un moyen d’élargir ses privilèges et on va donc en reparler un peu plus bas.
SUID et SGID
Lorsque vous lancez un exécutable, il s’exécute avec ses droits propres. Par exemple, si vous n’avez pas les droits en lecture sur un dossier, ls (qui est un exécutable) ne saura pas vous en lister le contenu car il héritera de vos droits au moment de lancer la commande.
De même, si vous n’avez pas les droits d’exécution sur un fichier, une commande qui permettrait d’en lancer une autre en cascade se verrait elle-même dans l’impossibilité de l’exécuter (et heureusement pour la sécurité de votre machine d’ailleurs). Il existe pourtant une possibilité de faire les choses un peu différemment.
SUID
On peut placer dans les permissions d’un exécutable un bit dit de SUID (Set User IDentification). Lorsque c’est fait, ce fichier s’exécutera non pas avec les droits de la personne qui le lance, mais avec ceux de son propriétaire. Cela se manifeste par un ‘s’ à la place du ‘x’ dans le résultat de ls -al au niveau des droits de l’utilisateur propriétaire. Un exemple vaut mieux qu’une explication compliquée :
> ls -al
drwxr-xr-x 24 prims devs 4096 Jul 7 11:00 ..
drwxr-xr-x 3 prims devs 4096 Jul 5 10:51 .
-rwsrwxr-- 1 prims devs 0 Jul 5 10:51 bar
drwxr-xr-- 2 prims devs 4096 Jul 5 10:51 foo
Ici, le fichier bar ne peut être exécuté que par “prims” ou les users du groupe “devs”. Toutefois, si “toto”, membre du groupe “devs”, exécute le fichier, bar travaillera avec les droits de “prims” et non pas ceux de “toto”.
SGID
Le SGID (Set Group IDentification, parfois aussi noté GUID) est très analogue au SUID. On le repère avec un ‘s’ à la place du ‘x’ dans les droits du groupe propriétaire. Dès lors, le fichier s’exécute aves les droits de ce groupe plutôt qu’avec ceux de l’utilisateur qui l’a lancé.
> ls -al
drwxr-xr-x 24 prims devs 4096 Jul 7 11:00 ..
drwxr-xr-x 3 prims devs 4096 Jul 5 10:51 .
-rwxrwsr-x 1 prims devs 0 Jul 5 10:51 bar
drwxr-xr-- 2 prims devs 4096 Jul 5 10:51 foo
Ici, tout le monde peut exécuter bar, mais ce dernier aura les droits du groupe “devs” dans tous les cas.
Sticky Bit
Petit bonus tant qu’on y est car la façon de le placer est analogue au SUID/SGID : on peut aussi placer sur les répertoires ce qu’on appelle le sticky bit. Cela se manifeste par un ‘t’ à la place du ‘x’.

Le sticky bit sert quasiment toujours à faciliter l’administration de dossiers partagés. Ce qu’il implique est assez simple : seul le propriétaire d’un fichier ou dossier peut le supprimer. Ainsi, même un fichier qui aurait les droits complets (777 / rwxrwxrwx) ne pourrait pas être supprimé par n’importe qui mais uniquement par son propriétaire légitime.
Les mettre en place
Pour cela je vous ramène aux explications sur chmod de la semaine dernière car je ne vais pas reprendre les bases de cette commande.
Si on utilise chmod par masque, il attend en fait quatre chiffres et non pas trois. Le premier de ces quatre chiffres permet de placer le SUID (4), SGID (2) ou le Sticky Bit (1). On peut bien évidemment en placer plusieurs à la fois (je rappelle que chacun de ces chiffres représente un bitfield). Lorsqu’on ne précise que trois chiffres comme la semaine dernière, il suppose que le premier est en fait à 0, ce qui signifie : “pas de SUID, pas de SGID, pas de sticky bit svp !”.
Si je reprends mon dossier fétiche :
> chmod 4777 bar
> ls -al
drwxr-xr-x 24 prims prims 4096 Jul 7 11:00 ..
drwxr-xr-x 3 prims prims 4096 Jul 5 10:51 .
-rwsrwxrwx 1 prims prims 0 Jul 5 10:51 bar
drwxr-xr-- 2 prims prims 4096 Jul 5 10:51 foo
On a bien placé le SUID avec cette commande et désormais tout le monde peut exécuter bar avec les droits de “prims”.
Attention : ce cas de figure de buffet à volonté où tout le monde peut exécuter pour le compte d’un user est typiquement une source d’intrusion potentielle. Il faut donc être très vigilant avec les SUID et SGID que vous mettez en place.
Pour mettre en place ou enlever ces bits avec la notation symbolique de chmod sans trop de surprise on utilisera : +s, -s, +t, -t, éventuellement avec u, g ou o comme restriction initiale (chmod u-s bar par exemple pour enlever le SUID du fichier bar).
Les repérer pour vérifier sa sécurité
Vous pouvez utiliser la commande find pour retrouver vos petits, ce qui est utile si vous voulez vérifier que vous n’avez pas trop ouvert les vannes (je ne le dirais jamais assez : c’est hyper important).

# lister tous les suids
> find / -perm -4000 2> /dev/null
# lister tous les sgids
> find / -perm -2000 2> /dev/null
# lister les fichiers sgids uniquement (voir plus bas)
> find / -perm -2000 -type f 2> /dev/null
# lister tous les sticky bits
> find / -perm -1000 2> /dev/null
Normalement, si vous lancez ça sur votre machine ou votre serveur, vous aurez un certain nombre de suid, notamment /usr/bin/passwd sans quoi les utilisateurs ne pourraient pas modifier leur propre mot de passe ou encore /usr/bin/sudo et /usr/bin/su donc on va reparler dans un instant.
Pour les SGID, pas de panique s’ils sont très nombreux, regardez bien de quoi il s’agit. Il est en effet commun de mettre le SGID sur des répertoires car cela assure que les fichiers et sous-répertoires créés dedans auront le même groupe propriétaire, ce qui est souvent souhaitable dans les répertoires de projets de développements ou arborescences liées à un site web par exemple. Vous pouvez raffiner la commande avec “-type f” pour ne lister que les fichiers, ce qui va restreindre le champ de recherche pour vos failles de sécurité.
Soyez vigilants
Vous en avez l’habitude maintenant, je vous bassine avec la sécurité dès qu’on traite d’un sujet qui a des impacts dessus.
On ne s’en rend pas toujours compte mais il est très simple de créer une faille de sécurité monumentale avec deux ou trois trucs qui peuvent paraître anodins.
Par exemple, donner le suid à un exécutable qui appartient à root doit se faire avec beaucoup de précautions : “est-ce que mon exécutable peut lancer en cascade d’autres exécutables ?” Si oui, il y a danger, car des derniers seront de fait lancés par root puisque c’est ce niveau de privilège qu’a l’exécutable parent. L’utilisateur pourrait détourner cela pour relancer un shell qui aurait donc les droits de root (et là c’est Las Vegas baby !).
Restez donc comme toujours prudents. Les failles de base peuvent être facilement évitées si on réfléchit à deux secondes avant de faire une action qui a une incidence sur les permissions.

Leave a Reply