Puis-je créer un * super * super-utilisateur afin que je puisse réellement avoir un utilisateur qui peut refuser l'autorisation de rooter?
Je pensais qu'il pourrait être avantageux d'avoir un utilisateur avec des autorisations supérieures à l'utilisateur root.
Vous voyez, je voudrais garder toutes les activités et presque tous les privilèges d'utilisateur root existants exactement comme ils le sont maintenant.
Cependant, j'aimerais pouvoir refuser des privilèges à rooter sur une base extrêmement isolée au cas par cas.
Un des avantages de cela me permettrait d'empêcher l'installation de certains fichiers indésirables lors des mises à jour. Ceci n'est qu'un exemple d'un avantage possible.
Parce que les mises à jour apt-get sont exécutées par root ou avec les privilèges Sudo, apt-get a la possibilité de remplacer certains fichiers indésirables lors des mises à jour.
Si je pouvais refuser ces privilèges à ces fichiers particuliers, je pourrais les définir comme un lien simulé vers /dev/null ou peut-être avoir un fichier d'espace réservé vide qui pourrait avoir des autorisations qui empêcheraient le fichier d'être remplacé pendant la mise à jour.
De plus, je ne peux pas m'empêcher de me rappeler une ligne qui a été dite dans une interview avec l'un des créateurs d'Ubuntu lorsque le gars a dit quelque chose sur la façon dont les utilisateurs peuvent mieux nous faire confiance (en se référant aux développeurs Ubuntu) "parce que nous avons racine "qui faisait référence à la façon dont les mises à jour du système sont effectuées avec l'autorisation root.
Modifier simplement la procédure d'installation pour dire que contourner ce problème n'est absolument pas ce qui m'intéresse ici. Maintenant que mon esprit a le goût de l'idée d'avoir le pouvoir de refuser l'accès root, je voudrais trouver un moyen d'y arriver juste pour le faire.
Je viens d'y penser et je n'ai pas passé de temps sur l'idée jusqu'à présent et je suis assez confiant que cela pourrait être compris. Cependant, je suis curieux de savoir si cela a déjà été fait ou si ce n'est peut-être pas une nouvelle idée ou un nouveau concept.
Fondamentalement, il semble qu'il devrait y avoir un moyen d'avoir un super super-utilisateur qui n'aurait une autorisation au-delà de celle du système que d'un degré.
Remarque: Bien que je pense que la réponse acceptée correspond le plus aux critères, j'aime vraiment la réponse de @CR. aussi.
Je voudrais créer un utilisateur réel plus haut sur l'arbre (moi) mais je suppose que je vais juste devoir m'asseoir un jour quand j'aurai le temps de le comprendre.
De plus, je n'essaie pas de choisir Ubuntu ici; Je ne l'utiliserais pas comme ma distribution principale si je me sentais négatif à ce sujet.
L '"utilisateur" que vous souhaitez s'appelle LSM: module de sécurité Linux. Les plus connus sont SELinux et AppArmor.
Par cela, vous pouvez empêcher certains binaires (et leurs processus enfants) de faire certaines choses (même si leur UID est root). Mais vous pouvez autoriser ces opérations à getty et ses processus enfants afin que vous puissiez le faire manuellement.
Vous comprenez mal le concept de l'utilisateur root.
En clair, root est au "sommet de l'arborescence".
Et si vous décidez un jour d'avoir un "super super utilisateur", puis le mois prochain, un "super super super utilisateur" (!). Jusqu'où "monter" l'arbre voudriez-vous aller? Comment mélangeriez-vous toutes les autorisations et la hiérarchie pour que cela fonctionne? Qui est toujours au sommet? Quelqu'un doit être au sommet, et c'est root. Fin de l'histoire.
Les solutions présentées ici - y compris AppArmor et SELinux - ne changent pas vraiment cela. Ils permettent simplement un contrôle plus fin du grain sur les autorisations et les processus root.
Il me semble que votre processus de mise à jour ne convient pas au résultat souhaité. Mais ce n'est pas du tout la faute de l'utilisateur root. Au lieu de trop compliquer les choses, pensez à root comme l'utilisateur de permission de plus haut niveau, et puis tout le reste, vous devez travailler vers le bas.
Je sais que certaines personnes noteront cela, mais il n'y a pas de niveau supérieur dans la hiérarchie des utilisateurs, et toutes les autres solutions donnent simplement un contrôle légèrement différent sur le fonctionnement des autorisations root. Mais ils ne créent un nouvel utilisateur, avec des autorisations plus élevées.
Vous ne pouvez pas avoir un utilisateur avec "plus d'autorisations" que root car root représente le plus haut niveau d'autorisations possible. Utiliser une phrase comme "plus de contrôle que root" est une contradiction - root a le contrôle total et toutes les autorisations possibles, donc il n'y a rien qui puisse être fait au-dessus.
Si vous souhaitez simplement empêcher les fichiers ou les répertoires d'être modifiés/supprimés, définissez simplement l'indicateur immuable sur eux.
chattr +i <file>
Même root ne pourra rien leur faire à moins que le drapeau ne soit supprimé. Il est également possible d'utiliser le système de conteneur/espace de noms pour empêcher l'accès root, mais cela semble exagéré pour ce dont vous avez besoin.
Au lieu d'avoir un super-super-utilisateur, vous pouvez limiter root. voir Quelles sont les différentes façons de définir les autorisations de fichiers, etc. sur gnu/linux
Il existe également AppArmor et SELinux.
Et/ou configurez
Sudo, afin de ne pas céder les privilèges root complets. Vous pouvez le configurer pour qu'un utilisateur ne puisse exécuter que des commandes pré-approuvées, avec des arguments pré-convenus.Vous pouvez également utiliser la virtualisation pour restreindre root:
- cgroups, namespaces, chroot etc (docker fait cela)
- Xen
- Virtualbox
Voir aussi
etckeeper: cette révision d'outil contrôle le/etcrépertoire, et se synchronise avec apt. Par défaut, il n'est pas sécurisé, une installation malveillante pourrait le saboter, mais vous pouvez également le faire pousser les modifications vers un référentiel de sauvegarde pare-feu.Utilisation du contrôle de révision en général, avec un référentiel de sauvegarde coupe-feu. Cette aide en cas de corruption accidentelle et intentionnelle et de défaillance matérielle.
Les référentiels de sauvegarde pare-feu peuvent se trouver sur une autre machine, sur Internet ou sur une autre machine virtuelle (ou hôte de machine virtuelle).
Pour les logiciels comme [~ # ~] apt [~ # ~] , qui en fonctionnement normal nécessitent un accès à presque tout le système, la restriction est problématique. Même si vous l'empêchez d'accéder à certaines parties du système, il existe très probablement plus de possibilités pour un distributeur malveillant de contourner. Par exemple, en remplaçant une bibliothèque ou simplement un binaire ou en ajoutant un changement de configuration malveillant, que la racine non restreinte va éventuellement utiliser.
En fonction de la quantité de restrictions que vous imposeriez, certains scripts d'installation risquent de se casser.
Pour savoir comment restreindre les applications et les utilisateurs, vous pouvez écrire une stratégie AppArmor ou SELinux. Une telle politique qui serait plus supportée dépend de votre distribution: basée sur Debian ont un meilleur support pour AppArmor tandis que les distributions basées sur Fedora/RHEL activent SELinux par défaut.
AppArmor et SELinux fonctionnent tous deux sur les listes blanches , qui contiennent des règles pour autoriser (ou refuser) des actions spécifiques. Les politiques sont appliquées à un processus à exec , de même les utilisateurs peuvent être limités lorsqu'une politique est appliquée à leurs processus à la connexion. Une politique bien pensée ne peut être contournée (si les bogues du noyau ne sont pas pris en compte). Le processus confiné s'exécutant en tant que root (uid 0) est limité par la stratégie configurée et ne peut pas le modifier à moins qu'il ne soit explicitement autorisé dans la stratégie.
Le langage de stratégie AppArmor définit une règle de refus , qui peut être utilisée pour créer une liste noire politique . Un bon endroit pour commencer avec AppArmor est AppArmor pages de manuel , wiki et en regardant la configuration existante sur votre distribution dans /etc/apparmor.d/.
De nombreux documents d'administration et de développement SELinux sont fournis dans wiki SELinux . SELinux politique de référence est hébergé sur github.
Je ne peux pas croire que personne n'ait mentionné l'épinglage apt ...
Il y a quelques années, Microsoft a publié un correctif qui empêchait les machines Windows 10 de parler à nos anciens contrôleurs de domaine Samba NT4. Lorsque le problème a été détecté, nous avons épinglé le package Samba pour conserver la version actuelle et apt fonctionnait toujours correctement.
Une procédure complète Debian pas à pas explique bien le processus:
Dans /etc/apt/preferences (ou un nouveau fichier sous /etc/apt/preferences.d/), ajoutez du texte pour spécifier le package et la version:
Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900
Consultez la documentation pour la syntaxe exacte, mais c'est la façon rapide et sale dont nous avons épinglé une version de package. Root pourrait le contourner, comme root peut toujours le faire, mais cela résout le problème des gestionnaires de packages essayant de mettre à niveau automatiquement les packages sur vous.
REMARQUE: cette réponse suppose que vous avez un problème XY
C'est en fait assez simple.
Root est votre "super super utilisateur"
Créez un compte appelé "admin" et donnez-lui toutes les autorisations de root, sauf celle que vous ne voulez pas.
Créez ensuite un utilisateur appelé bob et laissez-le "devenir administrateur". En utilisant su ou même Sudo.
Vous avez maintenant un utilisateur normal (bob) un super utilisateur qui peut faire des trucs d'administration (admin) et un super super utilisateur (root).
Si vous voulez changer le nom "root" en quelque chose d'autre, vous pouvez même le faire. Techniquement, seul l'ID utilisateur (0) est important.
Si vous souhaitez simplement empêcher l'installation de fichiers spécifiques, la restriction des autorisations root n'est pas la solution. Il convient également de noter que les réponses classiques (fichiers immuables ou LSM) ne fonctionneront pas pour votre cas d'utilisation particulier, car APT (et la plupart des autres gestionnaires de packages), renfloueront s'ils le peuvent '' t installer des fichiers.
La vraie question que vous voulez poser est:
Existe-t-il un moyen d'empêcher APT d'installer des fichiers spécifiques?
C'est quelque chose de complètement différent de ce que vous demandez à plusieurs niveaux.
Maintenant, quant à cette question, je ne suis pas sûr à 100% moi-même, mais je sais qu'un certain nombre d'autres gestionnaires de packages ont des options pour empêcher l'installation de fichiers spécifiques (par exemple, le système Portage de Gentoo a l'option INSTALL_MASK=, qui accepte en fait les modèles de correspondance de style Shell des éléments à ne pas installer). Je serais plus que disposé à parier qu'une telle option existe pour APT (ou peut-être dpkg lui-même).
Vous pouvez exécuter un hyperviseur de type 1 comme hyperviseur Xen et avoir cet hébergement de votre système d'exploitation normal en tant qu'invité virtualisé. L'hyperviseur contrôle le système d'exploitation invité virtuel à un niveau "plus profond" que root car il contrôle le matériel (virtuel) sur lequel le système d'exploitation invité s'exécute.
Vous pouvez programmer l'hyperviseur pour manipuler le système d'exploitation invité de différentes manières, y compris la modification des autorisations, la création et l'application de sauvegardes, le raccordement de certaines modifications ou instructions dans le système d'exploitation invité pour injecter des fonctionnalités supplémentaires, la validation, etc. Ce serait un moyen valide et potentiellement utile pour implémenter un système de type Unix avec un "utilisateur" (en fait une fonction de l'hyperviseur) pour "faire des choses que même root ne peut pas faire"
Mon sentiment que cette approche est probablement exagérée
Mettez une copie de sauvegarde dans un endroit sûr. Après toute installation/mise à jour, remplacez immédiatement les fichiers spécifiques de cette sauvegarde. Ainsi, aucune erreur pour gâcher l'installation mais vous récupérez toujours le ou les fichiers que vous souhaitez conserver.
Travailler à partir d'un lecteur monté
Notez que c'est surtout une réponse conceptuelle, mais je pense que cela devrait fonctionner et être en esprit avec ce que vous voulez réaliser.
Laissez le système X être votre système de travail et le système Y un autre système que vous contrôlez
- Montez un répertoire à partir de Y comme lecteur dans X
- Configurez les droits de telle manière que l'utilisateur root de X ait des droits sur tout ce qui se trouve sur ce lecteur monté, à quelques exceptions près
Maintenant, vous avez votre "racine de travail" qui peut presque tout faire, et vous avez votre "super racine", le compte racine réel du système Y, qui peut vraiment tout faire.
Jetez un oeil à cgroups et espaces de noms Linux comme méthode alternative pour atteindre ce type d'objectif, ainsi que des outils basés sur eux comme Docker et lxd .
Ces outils vous permettent, entre autres, de limiter les parties du système de fichiers qu'un processus s'exécutant en tant que "racine" peut voir, de limiter les processus qui lui sont visibles et de ne fournir que certains capacités au " utilisateur root.
DÉSINSTALLER Sudo
Que diriez-vous de désinstaller Sudo et symlink /bin/su à /bin/false? Ajoutez à cela que vous devez vous assurer que root ne peut pas se connecter via ssh et que vous avez verrouillé le système.
Cela fait de root le Super * Super User, et tout le monde est subordonné à cela.
Pour les fichiers remplacés lors des mises à jour, n'effectuez simplement aucune mise à jour. Plus réaliste, changez les autorisations des fichiers en 440 ou 444 donc ils ne peuvent pas être écrits. Ou mettez-les dans un référentiel git, donc s'ils sont écrasés, il peut être annulé.