L'utilisateur root peut-il être supprimé d'un système * nix pour empêcher l'escalade de privilèges?
Une fois qu'un système * nix est correctement configuré et renforcé, est-ce une stratégie envisageable pour supprimer tous les super utilisateurs/super utilisateurs? Y a-t-il des avantages à supprimer complètement root d'un système pour empêcher complètement les exploits d'escalade de privilèges de super-utilisateur?
Edit: Plus précisément: le super utilisateur (root, uid = 0 ou autre) peut-il être entièrement remplacé par un système basé sur les capacités?
Même si vous le vouliez, je ne pense pas que vous pouvez supprimer l'utilisateur root. De Wikipedia :
Sur les systèmes de type Unix, par exemple, l'utilisateur avec un identifiant utilisateur (UID) de zéro est le superutilisateur, quel que soit le nom de ce compte.
et une grande partie du code du noyau que les vulnérabilités exploitent fait des trucs comme
// become root
uid = 0;
...
if (uid == 0)
// do some protected thing
Le superutilisateur n'est donc pas vraiment un "compte utilisateur", c'est littéralement le numéro 0. Si vous pouvez trouver un exploit pour définir uid = 0 alors bam! votre processus a Sudo, qu'il existe ou non un compte utilisateur nommé "root".
MODIFIER LES COMMENTAIRES D'ADRESSAGE: plusieurs versions de Linux ajoutent un "!" au mot de passe de la racine dans le /etc/shadow fichier de mot de passe (un caractère qui ne peut pas être généré avec la fonction de hachage de mot de passe) ce qui rend impossible la connexion en tant que root. Cela arrête certains types d'attaques d'escalade de privilèges root basées sur le crackage du mot de passe root, mais le type le plus dangereux d'escalade de privilèges est basé sur des attaques de dépassement de tampon qui écrasent la variable uid d'un processus pour être uid=0, à quel point ce processus est root .
Comme d'autres l'ont fait valoir, cela n'a aucun sens de "supprimer" l'UID racine (qui est représenté sous UNIX comme l'UID 0). J'irais même plus loin et je dirais que cela n'a aucun sens de geler un système pour qu'il n'ait aucun moyen d'accorder de nouveaux privilèges. A noter que cette réponse est très opiniâtre et vague, car le sujet à couvrir est énorme. Voyons d'abord ce que signifie être root sur * NIX. Je vais commenter Linux car c'est le NIX * le plus populaire et il est livré avec des méthodes spécifiques. Espérons que d'autres pourront couvrir les familles BSD. Distinguons ce que signifie racine dans le contexte de:
- Contrôle d'accès discrétionnaire
- Modules de sécurité Linux
- Capacités UNIX
- Espaces de noms d'utilisateurs
Notez que dans tous les cas, cela n'a absolument aucun sens d'appliquer aveuglément des restrictions de privilèges à l'échelle du système à tous les binaires qui s'exécutent actuellement en tant que root. Ces privilèges existent souvent pour une raison. Vous devez donc lire le résumé ci-dessous pour expliquer comment vous pouvez affecter des services spécifiques que vous exécutez pour vos utilisateurs non privilégiés et que vous souhaitez protéger contre l'exploitation.
Contrôle d'accès discrétionnaire
La plupart des autorisations d'accès aux fichiers sur les systèmes * NIX sont obligatoires par le modèle DAC. De nombreuses interfaces du noyau et des mécanismes IPC sont résumés sous forme de fichiers, c'est donc une considération assez importante. Il s'agit du modèle avec un identifiant de propriétaire, un identifiant de groupe et des autorisations de lecture/écriture/exécution pour le propriétaire, membres du groupe et autres identités. Il est également livré avec les bits suid et sgid, mais je vais les garder pour le moment.
Par défaut, l'UID 0 contourne toujours les vérifications DAC. Cela est dû au fait que l'UID 0 possède la capacité CAP_DAC_OVERRIDE UNIX (voir ci-dessous). Les processus qui suppriment automatiquement cette capacité devront obéir à DAC, bien que la plupart des fichiers système de votre distribution soient de toute façon possédés et accessibles en écriture par root. La suppression de cette fonctionnalité peut protéger les fichiers utilisateur dans une certaine mesure mais ne protégera pas le système lui-même. Il est également très probable qu'un utilisateur root sans cette capacité (et sans les moyens directs d'obtenir d'autres capacités) puisse modifier logind, votre image du noyau ou d'autres fichiers clés afin de corrompre ou de prendre le contrôle de votre système.
Modules de sécurité Linux
En plus des vérifications DAC, tous les appels système sous Linux passent par un module de noyau enfichable qui implémente l'interface Linux Security Module . Ceux-ci pourraient être utilisés pour refuser des privilèges à rooter.
Par exemple, SELinux utilise le concept de rôles à cette fin. Sur toutes les politiques par défaut des distributions que je connais, votre démon de connexion ouvrira vos sessions racine avec un rôle limité, et vous devrez passer explicitement à un rôle appelé sysadm_r avant de pouvoir effectuer la plupart des opérations root traditionnelles. Vous devez écrire une stratégie pour empêcher que root soit semblable à root avec d'autres rôles. Néanmoins, comme les LSM vous permettent d'écrire une stratégie de contrôle d'accès obligatoire, vous pouvez effectivement limiter les privilèges root de cette façon. Cependant, l'aspect agréable est que vous pouvez piéger efficacement les tuples utilisateur: rôle dans leurs rôles, et vous pouvez fournir des rôles de manière sélective en fonction de la façon dont vous vous connectez. Cela permettrait de limiter la portée d'un compte racine spécifique à l'échelle du système.
Capacités UNIX
Je ne veux pas paraphraser la page de manuel sur les capacités mais essentiellement, les capacités permettent aux identités des utilisateurs d'interagir avec des interfaces spécifiques du noyau. Par exemple, CAP_CHOWN vous permet de modifier le propriétaire d'un fichier. Par défaut, root a la plupart des capacités activées (si je me souviens bien, CAP_MAC_ADMIN ou CAP_MAC_OVERRIDE ne sont pas activés par défaut) et les autres identités n'en ont pas.
Vous pouvez cependant supprimer certaines fonctionnalités de votre propre ensemble, vous pouvez donc, en tant que processus racine, vous transformer en un processus non privilégié, tant que vous disposez du CAP_SET_FCAP et CAP_SET_PCAP capacités. Notez qu'il a été avancé que de nombreuses autres capacités peuvent être utilisées pour regagner des privilèges complets. Je ne trouve pas la liste de ces capacités pour le moment, mais vous devez savoir que vous devez sérieusement réfléchir à la façon dont une capacité que vous laissez à vos processus racine peut être exploitée pour un compromis supplémentaire.
Tandis que le DAC contrôlait les accès aux fichiers, les capacités, sans doute, contrôlent l'accès et le comportement des appels système (et le MAC LSM contrôle les deux). Vous devez lire les manuels de nombreux appels afin de comprendre ce que fait chaque capacité.
Il y a des critiques sur l'adéquation des capacités pour Linux. Kerrisk a soutenu dans "" CAP_SYS_ADMIN: la nouvelle racine " que certaines capacités sont si fortement utilisées que les avoir signifie avoir les pleins pouvoirs. Cela suggère que vous ne pouvez pas simplement vous débarrasser du concept de super-utilisateur. Vous devrez être extrêmement privilégié au moins pour démarrer et configurer votre système, et pour fournir certains services dans le noyau. Dans les systèmes MAC qui offrent de fortes opportunités de confinement, vous rencontrez souvent le problème de la nécessité d'obtenir à nouveau un privilège (par exemple, sur SELinux, vous devrez peut-être changer le rôle en sysadm_r pour effectuer une opération de maintenance). De même, si vous vous débarrassiez de ces capacités, seriez-vous en mesure de (re) démarrer de nouveaux services privilégiés? La capacité de le faire ne serait-elle pas équivalente à être pleinement privilégiée?
Espaces de noms d'utilisateurs Linux
Les espaces de noms vous permettent, très vaguement, de fournir une vue différente de votre système aux processus qui y sont exécutés. Vous pouvez utiliser des espaces de noms de montage pour changer les fichiers qu'un processus et ses enfants peuvent voir et modifier, ou des espaces de noms de réseau pour fournir différentes interfaces réseau et configurations système. Ceci est utile pour les personnes qui fournissent des services PaaS, par exemple. Les espaces de noms d'utilisateurs vous permettent de mapper toutes les identités d'utilisateurs à l'intérieur d'un espace de noms à une seule à l'extérieur. Cela signifie que vous pouvez avoir un sous-système avec un utilisateur racine qui peut faire tout ce qu'il veut à l'intérieur de l'espace de noms et qui est mappé à un utilisateur non privilégié en dehors de l'espace de noms.
Quel est l'intérêt de cela exactement? Si quelqu'un avait un exploit sur votre noyau qui lui permet de remonter à la racine, les avantages des espaces de noms d'utilisateurs sont sans objet. Cependant, si l'exploit cible un binaire suid, un processus non privilégié qui accède aux privilèges root dans son espace de noms ne pourra toujours pas affecter le système d'exploitation hôte. Notez que les solutions de confinement comme les espaces de noms ne font que déplacer vos limites de défense. Au lieu de prouver que tous vos processus privilégiés sont sans défaut et ne peuvent pas être exploités, vous devez prouver qu'un processus entièrement privilégié à l'intérieur de l'espace de noms ne peut pas affecter le système d'exploitation hôte via les canaux de communication que vous laissez ouverts entre le système d'exploitation hôte et l'espace de noms. En fin de compte, si vous avez besoin d'un service privilégié à l'intérieur de votre espace de noms pour avoir accès à une ressource, compromettre ce service accordera l'accès à cette ressource.
Et maintenant? Pouvons-nous fournir des UNIX entièrement confinés?
Toutes ces méthodes ci-dessus vous permettent de limiter les services à des privilèges spécifiques (et avec des mises en garde spécifiques, soit dans des combinaisons (DAC + caps) ou seuls (LSM, espaces de noms). Vous pouvez également les combiner pour fournir une défense en profondeur. Cependant, la question de Que le confinement de tout soit bénéfique est très indépendant de la façon dont vous arbitrez les privilèges et représentez le concept de privilège complet (CAP_SYS_ADMIN, UID 0, utilisateur privilégié sans espace de nom, concept spécifique de votre LSM).
Lorsque vous écrivez un système d'exploitation et que vous souhaitez l'adapter aux besoins de ses utilisateurs, vous devez fournir des moyens pour le mettre à jour et le reconfigurer, et pour exécuter de nouveaux services. Si la maintenance du système implique des opérations telles que la mise à jour de vos services de sécurité, des politiques de contrôle d'accès, du noyau et des modules matériels, etc., vous devez soit fournir un moyen à un utilisateur humain d'agir en tant qu'acteur pleinement privilégié, soit en avoir un troisième -système de parti qui peut adapter votre système d'exploitation et déployer la version adaptée au-dessus des données de votre utilisateur. Il existe des contextes de haute sécurité où ce dernier peut être souhaitable (et très franchement, c'est, conceptuellement, aussi simple que d'exécuter une machine virtuelle). Dans le cas de l'informatique à usage général par une population d'utilisateurs qui entretiennent eux-mêmes leurs systèmes, vous ne pouvez cependant pas vous débarrasser d'identités entièrement privilégiées.
Le processus d'initialisation doit d'abord s'exécuter en tant que root. Mais fondamentalement, la définition de root n'est pas qu'il s'agit d'un utilisateur avec un identifiant de 0, c'est un propriétaire de processus ayant la possibilité d'accéder aux routines du noyau. Vous pouvez appliquer un système où, pour AAA, vous exécutez uniquement les commandes liées aux travaux soumis, mais à part cela, il n'y a aucune raison de supprimer l'utilisateur root. L'autre chose est: ce ne sont pas les comptes root qui rendent les systèmes attrayants, c'est le fait que les services exécutés sur les machines ont des données ou sont capables de transmettre des données qui sont au centre.
en fait, tous les 'utilisateurs' peuvent être supprimés ... les noyaux avec juste un programme binaire lié statique effectuant une tâche fonctionnent parfaitement sans aucun fichier/etc/passwd. Bien sûr, le concept de uids et euids existe toujours.
si vos systèmes effectuent une tâche spécifique ... supprimez-la tout simplement. système de fichiers, chargeur de démarrage, bibliothèques, le reste de la merde inutile. et exécutez simplement votre tâche DIRECTEMENT dans le noyau. (le redémarrer à partir de la rom est à nouveau une histoire différente;) bien sûr, s'il existe des vulnérabilités à distance dans votre code, ils peuvent toujours y accéder, mais il n'y a pas de Shell, ils sont donc limités au code qu'ils peuvent insérer à distance.
- cela étant dit - sur - les systèmes les plus normaux - - la plupart des hacks - à uid0 ne se fait pas en brutalisant les mots de passe ou en interceptant le trafic ... mais en utilisant toutes les conneries construites autour de lui pour - empêcher cela -. spécifiquement Sudo, traceroute, etc. la plupart des exploits de l'utilisateur 'www' à 'root' -requiert- un binaire suid ... et devinez ce que sont su et Sudo.
une fois qu'un système est terminé ... il n'y a en fait aucune raison apparente de conserver toutes les choses "d'accès", après tout, s'il y a une raison de réparer les choses, on peut mettre à jour l'image entière de la plateforme de développement au déploiement infra en flash ou stockage eeprom plutôt que d'y accéder pour exécuter votre éditeur/compilateur localement ou autre.