Mythe ou réalité: SELinux peut confiner l'utilisateur root?

J'ai lu ou entendu quelque part (peut-être dans le cours SELinux de LinuxCBT ; mais je ne suis pas sûr) qu'il existe des serveurs Linux en ligne, pour lesquels le mot de passe de l'utilisateur root est également donné. Le serveur Linux est renforcé en utilisant les règles SELinux, de sorte que tout le monde peut se connecter avec l'utilisateur root, mais ne peut pas nuire au système d'exploitation.

Cela me semble être un mythe, mais je voulais m'assurer: est-il possible de durcir une boîte Linux (éventuellement avec SELinux), de sorte que même l'utilisateur root ne puisse pas faire d'activités malveillantes spécifiques dessus? (Exemples: suppression de fichiers système, effacement de fichiers journaux, arrêt de services critiques, etc.)

Une telle boîte Linux sera un excellent point de départ pour la construction d'un pot de miel .

Edit: Sur la base d'une réponse (maintenant supprimée) et d'un peu de recherche sur Google, j'ai obtenu au moins deux liens qui pointaient vers des serveurs Linux durcis. Malheureusement, les deux serveurs sont en panne. Pour mémoire, je vais copier-coller les descriptions ici:

1) Sur http://www.coker.com.au/selinux/play.html :

Accès root gratuit sur une machine SE Linux!

Pour accéder à ma machine de jeu Debian ssh sur play.coker.com.au en tant que root, le mot de passe est ...

Notez que ces machines nécessitent beaucoup de compétences si vous voulez les faire fonctionner avec succès. Si vous devez demander si vous devez en exécuter un, la réponse est "non".

Le but de ceci est de démontrer que toute la sécurité nécessaire peut être fournie par SE Linux sans aucune autorisation Unix (cependant il est toujours recommandé que vous utilisiez également les autorisations Unix pour les serveurs réels). Cela vous donne également la possibilité de vous connecter à une machine SE et de voir à quoi cela ressemble.

Lorsque vous vous connectez à une machine de lecture SE Linux, assurez-vous que vous utilisez l' option -x pour désactiver le transfert X11 ou définissez ForwardX11 no dans votre fichier / etc / ssh / ssh_config avant de vous connecter. Assurez-vous également que vous utilisez l'option -a pour désactiver le transfert d'agent ssh ou définissez ForwardAgent no dans votre fichier / etc / ssh / ssh_config avant de vous connecter. Si vous ne désactivez pas correctement ces paramètres, la connexion à la machine de jeu vous exposera au risque d'être attaqué via votre client SSH.

Il existe un canal IRC pour en discuter, c'est #selinux sur irc.freenode.net .

Voici une FAQ rapide

2) Sur http://www.osnews.com/comments/3731

Le but de Gentoo renforcé est de rendre Gentoo viable pour les environnements de serveurs de production à haute sécurité et haute stabilité. Ce projet n'est pas un projet autonome disjoint de Gentoo proprement dit; il est destiné à être une équipe de développeurs Gentoo qui se concentrent sur la fourniture de solutions à Gentoo qui offrent une sécurité et une stabilité solides. Cette machine est la machine de démonstration SELinux de Hardened Gentoo . Son utilisation principale est de tester et d'auditer l'intégration et la politique SELinux.

Réalité: oui, SELinux peut confiner l'utilisateur root.

Ceci est possible parce que SELinux ne se soucient pas vraiment de l'utilisateur Unix courant: il voit tout est un méta - données supplémentaire appelé le contexte (qui comprend, entre autres domaines, un domaine champ) et qui permet de SELinux décide si l'action demandée peut être autorisée ou ne pas.

Ce que l'on conçoit habituellement en tant qu'utilisateur root serait mappé dans SELinux en tant qu'utilisateur root Unix exécutant les domaines SELinux unconfined_tou sysadm_t. Il s'agit de l'utilisateur root omnipotent à pleine puissance classique.

Cependant, on pourrait parfaitement configurer son système pour engendrer un shell racine (je veux dire shell utilisateur Unix racine) exécutant le domaine restreint user_tSELinux. Selon les politiques SELinux, un tel shell ne serait pas différent de tout autre shell d'utilisateurs restreints et n'aurait aucun privilège spécial sur le système, confinant ainsi efficacement l'utilisateur root.

En dehors d'un point de vue expérimental, faire une telle chose est littéralement inutile, mais une pratique similaire trouve son chemin dans le monde réel. Un exemple classique serait un administrateur de base de données devant pouvoir arrêter / démarrer les démons de base de données, modifier les fichiers de configuration, etc. Sans SELinux, toutes ces actions nécessiteraient que l'utilisateur escalade vers les privilèges root (même si c'est normalement pour un seul ligne de commande via l' sudooutil par exemple, même si cela peut être sujet à des fuites).

Grâce à SELinux, nous pourrions donner à cet utilisateur un véritable shell racine, mais au lieu d'exécuter unconfined_tou de sysadm_tdomaines, il exécutera le dbadm_tdomaine. Cela signifie qu'il aura plus de privilèges qu'un utilisateur restreint, mais ces nouveaux privilèges seront limités à ce qui est nécessaire pour administrer le serveur de base de données: cet utilisateur ne pourra pas altérer d'autres services, fichiers ou exécuter d'autres commandes administratives que celles strictement requis pour faire son travail.

De la même manière, le serveur Web et les autres administrateurs de services pourraient également avoir d'autres shells racine fonctionnant en parallèle sur le même système, chacun verra son utilisateur Unix actuel être root , mais grâce à SELinux, chacun aura effectivement des privilèges différents limités à ce que est nécessaire à leurs propres fins .

Oui c'est possible. Mais pas très utile.

Vous pourriez théoriquement interdire à l'utilisateur root d'exécuter des binaires qui pourraient être utilisés à des fins malveillantes, en appliquant des politiques via quelque chose comme SELinux. Cependant, cela présente un problème, qui est que même si l'utilisateur root n'était initialement pas autorisé à faire quelque chose, il ou elle pourrait simplement utiliser d'autres méthodes pour modifier ou supprimer les politiques SELinux. En raison de ce problème, vous devrez effectivement interdire à l'utilisateur root d'effectuer une quelconque action, ce qui la rend peu utile.

Est-il possible de durcir une boîte Linux (éventuellement avec SELinux), de sorte que même l'utilisateur root ne puisse pas y faire d'activités malveillantes spécifiques?

Cela peut sembler bon marché, mais c'est facile: changez l'uid de la racine utilisateur en non nul. Allez simplement dans / etc / passwd et / etc / shadow, modifiez les entrées uid = 0 existantes de "root" à autre chose, puis ajoutez un compte nommé "root" dont l'uid n'est pas nul et inutilisé.

Il atteint le but sans. C'est aussi un moyen de prétendre que n'importe qui peut avoir un "accès root" sans réellement fournir des privilèges élevés.