Dans quels scénarios puis-je définir un bit SUID?

J'ai du mal à me concentrer sur le concept des bits SUID et pourquoi ils seraient utiles.

Par exemple, disons que j'ai un programme:

-rwsr-xr-x 1 root root 12364 Jan 12 2013 /usr/bin/foo

Ma compréhension est que le s dans le bit d'exécution pour le propriétaire de l'user signifie essentiellement que le file peut être exécuté par d'autres users avec l'autorité du propriétaire du file.

Pourquoi voudrais-je quelque chose comme ça? Pourquoi ne pas simplement changer le groupe pour le file afin qu'il fonctionne pour un groupe auquel tous les users appartiennent?

Setuid et setgid (et setcap là où il existe) sont les seuls moyens d'élever les privilèges. Autre que par ce mécanisme, un process peut renoncer à des privilèges, mais jamais les gagner. Par conséquent, vous ne pourriez pas faire quoi que ce soit qui nécessite des privilèges supplémentaires.

Par exemple, les programmes su et sudo doivent pouvoir exécuter des commands comme n'importe quel user. Par conséquent, ils doivent s'exécuter en tant que root, quel que soit l'user qui les a appelés.

Un autre exemple est ping . Les sockets TCP et UDP sont accessibles à tout user, car ces protocoles ont une notion de ports et un process peut prendre le contrôle d'un port (ce qui est appelé le liant), de sorte que le kernel sait où envoyer les packages. ICMP n'a pas de telle notion, de sorte que seuls les programmes exécutant en tant que root (ou avec la capacité appropriée) sont autorisés à requestr que les packages ICMP leur soient envoyés. Pour que n'importe quel user puisse exécuter ping , le programme ping doit avoir un privilège supplémentaire, c'est donc root setuid (ou setcap).

Pour un exemple de privilèges de groupe, considérez un jeu qui stocke les scores élevés locaux dans un file. Étant donné que seuls les scores élevés obtenus par les users doivent être stockés dans le file de score, le file de score ne doit pas être accessible en écriture par les joueurs. Seul le programme de jeu doit être autorisé à écrire dans le file de score. Donc, le programme de jeu est fait des games setgid, et le file de score est inscriptible par les games groupe mais pas par les joueurs.

Il existe une autre approche pour élever les permissions, qui consiste à démarrer des programmes qui nécessitent des privilèges supplémentaires à partir d'un programme de lancement privilégié. Lorsqu'un user souhaite effectuer une tâche nécessitant des privilèges supplémentaires, il exécute un programme frontal qui utilise une forme de communication inter-process pour effectuer l'action privilégiée. Cela fonctionne bien pour certains cas d'utilisation tels que ping (un programme ping pour parsingr les options et la progression du rapport, et un service ping-backend qui envoie et reçoit des packages), mais pas pour d'autres cas d'utilisation.

Le bit suid (ou sgid) provoque l'exécution d'un exécutable en tant qu'user / groupe différent de l'user qui l'appelle.

Si la seule raison pour cela est d'accéder à un file particulier, vous pouvez utiliser d'autres mécanismes pour rendre ce file inscriptible. Cependant, l'user pourrait faire n'importe quoi pour le file, par opposition aux seules choses que votre programme autorise.

Vous pouvez, par exemple, que votre programme autorise uniquement l'ajout d'une ligne à un file et uniquement dans un certain format. Mais si vous venez d'utiliser les permissions du système de files, l'user peut également supprimer des lignes du file. Ou mettre dans des lignes mal formatées.

Fondamentalement, un programme suid peut imposer une politique arbitraire. Les permissions de système de files ne peuvent pas. Par exemple, votre système a un programme suid /bin/su . Il vous donne un shell racine (par exemple), mais seulement si vous respectez une politique en premier, généralement, entrez le mot de passe root. Il n'y a aucun moyen de le faire avec les permissions seules.

La raison la plus courante est qu'un exécutable peut être exécuté en tant que root. Par exemple:

 find /bin/ -type f \( -perm -4000 -o -perm -2000 \) -ls | awk '{print $3,$NF}' -rwsr-xr-x /bin/su -rwsr-xr-x /bin/mount -rwsr-xr-- /bin/fusermount -rwsr-xr-x /bin/ping6 -rwsr-xr-x /bin/ping -rwsr-xr-x /bin/umount 

Ce sont toutes des commands qui peuvent être exécutées par des users réguliers mais qui ont besoin de privilèges élevés. mount est un exemple parfait, vous pouvez monter n'importe quel disque avec l'option user ou similaire dans /etc/fstab mais le assembly a besoin de privilèges root pour que le bit SUID soit défini.