Quelqu'un peut-il expliquer le mécanisme set-user-ID sous Unix? Quelle était la justification de cette décision de conception? En quoi est-il différent d'un mécanisme d'ID utilisateur efficace?
12
Quelqu'un peut-il expliquer le mécanisme set-user-ID sous Unix? Quelle était la justification de cette décision de conception? En quoi est-il différent d'un mécanisme d'ID utilisateur efficace?
Vous connaissez peut-être les autorisations normales de lecture, d'écriture et d'exécution pour les fichiers sous Unix.
Cependant, dans de nombreuses applications, ce type de structure d'autorisation - par exemple en accordant à un utilisateur donné une autorisation complète de lire un fichier donné, ou aucune autorisation de lire le fichier - est trop grossier. Pour cette raison, Unix inclut un autre bit d'autorisation, le set-user-IDbit. Si ce bit est défini pour un fichier exécutable, chaque fois qu'un utilisateur autre que le propriétaire exécute le fichier, cet utilisateur acquiert tous les privilèges de lecture / écriture / exécution du fichier du propriétaire en accédant à l'un des autres fichiers du propriétaire!
Pour définir le bit set-user-ID d'un fichier, tapez
chmod u+s filename
Assurez-vous que vous avez également défini l'autorisation d'exécution group-other; ce serait bien d'avoir également une autorisation de lecture sur les autres groupes. Tout cela peut être fait avec la seule déclaration
chmod 4755 filename
Il est également appelé UID enregistré. Un fichier lancé avec un bit Set-UID activé, l'UID enregistré sera l'UID du propriétaire du fichier. Sinon, l'UID enregistré sera le véritable UID.
Cet UID est utilisé pour évaluer les privilèges du processus pour effectuer une action particulière. L'EUID peut être changé en UID réel ou UID superutilisateur si EUID! = 0. Si EUID = 0, il peut être changé en n'importe quoi.
Un exemple d'un tel programme est passwd. Si vous l'énumérez en entier, vous verrez qu'il a un bit Set-UID et que le propriétaire est "root". Lorsqu'un utilisateur normal, par exemple "mtk", s'exécute passwd, il commence par:
Real-UID = mtk
Effective-UID = mtk
Saved-UID = root
man credentialsest une bonne source d'information dans ce cas. Voir aussi cette quête sur SO . Pour une explication historique, voir cet article archivé .
Plutôt que d'appeler "set UID" et "effective UID" un mécanisme, tout le concept des UID devrait être appelé ainsi. La justification de l'existence des divers UID est due à divers problèmes de séparation des privilèges. Même les utilisateurs réguliers (non privilégiés) doivent parfois faire des choses (accéder aux ressources) que seuls les utilisateurs privilégiés peuvent faire. Pour y parvenir facilement, les programmes peuvent changer leurs UID. Il en existe 3 types:
UID réel - l'UID propriétaire d'un processus
UID efficace - l'UID sous lequel un processus s'exécute actuellement - cela détermine les capacités réelles du processus à tout moment particulier. C'est aussi ce psque vous montre dans le champ USER.
UID de l'ensemble enregistré - espace réservé utilisé pour basculer entre les UID réels et effectifs
La nécessité pour le dernier provient du fait que les utilisateurs réguliers peuvent ne basculer entre ces trois et rien d' autre programme et un setuid doit généralement savoir en quelque sorte, qui était l'utilisateur qui l'a chargé (plus l'UID réel ne doit pas être changé depuis cela créerait un désordre encore plus grand).
L'expansion de mtk est bonne.
L' passwdexemple est celui de l'escalade de privilèges - passwd s'exécute toujours en tant que root car il doit modifier les fichiers que seul root est autorisé à modifier. Il est donc important que l'exécutable passwd ne soit pas sujet aux débordements de tampon, etc., de sorte qu'un utilisateur normal intelligent puisse être en mesure de le mettre à des fins auxquelles il n'était pas destiné.
Une autre raison est de protéger l'utilisateur de la même manière que vous pourriez utiliser susi vous êtes connecté en tant que root - afin de diminuer ou de restreindre vos privilèges pour des tâches spécifiques, et non de les augmenter. Par exemple, si j'ai la permission de démarrer un service démon qui ne nécessite pas l'accès à mes trucs et qui a ses propres trucs, c'est tout ce dont il a besoin (par exemple, un enregistreur), le lancer suid signifiera qu'il n'a accès qu'à ces trucs et pas le mien ou quelqu'un d'autre.
Notez qu'il est possible de définir uid par programme même si le bit suid n'est pas défini sur l'exécutable , cependant, cela ne fonctionnera pas pour l'escalade. C'est-à-dire que si vous êtes un utilisateur normal et que vous écrivez un programme qui définit uid à un moment donné lui-même, ce programme ne peut pas basculer vers root. Apache fonctionne de cette façon, je crois. Il est généralement démarré par root et possède un processus qui envoie ensuite des enfants qui commutent uid à un utilisateur non privilégié (par exemple, "httpd"). Ces processus enfants sont ce que fait le serveur Web réel.