utiliser un bit SUID pour supprimer des privilèges

C'est donc une description du système sur lequel je travaille:

un process "manager" engendre toutes les autres applications.
L'application du gestionnaire s'exécute en tant qu'user root .
donc maintenant, tout process généré génère également des privilèges d'user root .

Le troisième point fait clairement de mon application un problème de security, donc une solution serait de créer un user et un groupe distincts, disons «travailleur», puis engendre le process «joueur» en tant qu'user.

La mise en œuvre spécifique est la suivante:

chown le binary (player.out) à l'user du worker et le groupe chown worker:worker player.out
mettez le bit SUID dessus avec chmod a+s player.out .
- cela garantit que le process est démarré avec (au less) c'est EUID mis à «travailleur».
à l'intérieur de l'utilisation principale de l'application setregid() et setreuid pour définir le RUID à la même valeur que l'EUID:
```
 if(setregid(getegid(), getegid()) != 0) {} if(setreuid(geteuid(), geteuid()) != 0) {} 
```

Ma question est en deux parties:

Les process avec un set de bits SUID sont généralement la propriété de root et sont appelés setuid-applications pour indiquer (éventuellement) que leurs permissions sont élevées à l'user root quel que soit l'user qui a appelé le programme.
- existe-t-il un nom spécial pour les binarys qui utilisent le bit SUID pour déposer automatiquement des privilèges?
Y a-t-il une autre meilleure façon de s'assurer que l'application «joueur» laisse tomber les privilèges?

Edit : Je devrais préciser que je n'ai aucun contrôle sur le process "manager" qui engendre les autres process. J'ai seulement le contrôle sur mon application de player .

Lorsque vous indiquez correctement un bit SUID, définissez l'ID user effectif du nouveau process sur le propriétaire du file programme en cours d'exécution. Il n'y a pas de concept pour élever ou abaisser les privilèges. Souvent, l'user auquel un "suids" est root, mais il peut tout aussi bien en être un autre, et ne change pas vraiment le concept de SUID, en choisissant un autre, à part certains users ont access à certaines ressources. Cependant, l'user root est un peu spécial, et la page man pour setuid, explique les différences subtiles. Je ne pense pas qu'il y ait un nom spécial pour changer à un user non-root, et je n'ai jamais associé suid signifiant monter en privilège, juste changer d'user.
Puisque vous développez vous-même le maître qui s'exécute en tant que root, il peut définir un user après le forçage, mais avant d'exécuter le nouveau process, je ne vois pas que le bit suid doit être utilisé sur un exécutable, et incidemment si vous ne le faites pas , alors si n'importe quel ancien user a couru le joueur, puisque l'exécutable n'est pas suid, ils ne pourraient pas l'exécuter correctement puisque setuid échouera s'ils n'étaient pas root. Pour moi, cela semble être une meilleure security, que d'utiliser des bits suid sur des files exécutables.

— éditer 1

Ainsi votre manager (fonctionnant comme uid réel et efficace = 0) démarre le joueur et vous code / contrôle le joueur (pas le manager). Si vous ne faites rien de spécial, alors le joueur exécutera avec + uid = 0 effectif et vous voulez éviter cela.

Vous pouvez simplement changer d'user dans le lecteur, pas de bits SUID sur le lecteur, pas besoin.

La méthode habituelle est que le process maître forge, supprime les capacités ou modifie son ID user, puis exécute le nouveau process.