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

20

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.

MS Dousti
la source
2
Il a également été revendiqué ici . Bien que cela soit sûrement théoriquement possible, cela me semble difficile (sauf si vous limitez cet utilisateur root à un point tel qu'il ne peut rien faire d'utile). Il est difficile dans le meilleur des cas d'écrire des règles SELinux qui font vraiment ce que vous avez l'intention de faire.
Gilles 'SO- arrête d'être méchant'
4
Avec les noyaux récents, les utilisateurs non root peuvent créer des espaces de noms où ils ont l'UID 0. Comme ils ne sont pas UID 0 dans l'espace de noms de niveau supérieur, ils ne peuvent pas endommager le système. Ils n'ont intrinsèquement aucune possibilité de préjudice, contrairement à l'approche SELinux où toutes ces opportunités doivent être supprimées. Voir noyau: prise en charge des espaces de noms et séparer complètement deux comptes sans installer de systèmes d'exploitation séparés?
Gilles 'SO- arrête d'être méchant'
Dépend de votre pilote graphique, qu'il soit réellement sécurisé ou non.
Joshua

Réponses:

17

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 .

WhiteWinterWolf
la source
1

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.

strugee
la source
D'abord, j'étais aussi pessimiste que vous. Mais, en acquérant plus de connaissances, il semble qu'il ne soit pas nécessaire de "interdire à l'utilisateur root d'effectuer une quelconque action". Vérifiez ma réponse modifiée, qui comprend des liens et des informations vers des preuves de concepts. Malheureusement, ils ne sont plus disponibles; mais il semble que les implémentations n'étaient pas sévèrement restrictives.
MS Dousti
-5

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.

Otheus
la source
3
Eh bien oui, mais l' rootutilisateur n'est tout simplement pas réellement l'utilisateur root. La question est de savoir si le super utilisateur réel peut être limité de cette manière.
terdon
Cela semble dangereux - sauf que vous créez un autre compte avec uid 0 bien sûr. Mais cela reviendrait à renommer root et à réutiliser le nom "root".
Volker Siegel
La question se réfère uniquement à "root" qui n'est pas nécessairement équivalent au super-utilisateur, c'est-à-dire uid = 0. En de rares occasions, il s'agit d'une distinction utile.
Otheus
2
Néanmoins, le contexte montre clairement que l'OP demande si le super utilisateur, et non un utilisateur aléatoire dont le nom d'utilisateur est rootlimité de cette manière.
terdon
1
D'ACCORD. Au moins, veuillez modifier votre réponse et montrer comment ce que vous proposez pourrait être réalisé. Il continue d'être signalé comme de faible qualité en raison de sa longueur. C'est pourquoi cela fait baisser les votes.
terdon