Accès root qui ne peut pas changer le mot de passe root?

66

Nous avons un petit problème sur un serveur. Nous voulons que certains utilisateurs soient capables de faire, par exemple, sudoet de devenir root, mais avec la restriction que l'utilisateur ne peut pas changer le mot de passe root. C’est-à-dire une garantie que nous pouvons toujours nous connecter à ce serveur et devenir root, quoi que fassent les autres utilisateurs.

Est-ce possible?

244an
la source
32
Vous pouvez utiliser sudopour accorder une autorisation uniquement pour une application spécifique à privilèges root. De cette façon, l'utilisateur ne sera pas autorisé à changer le mot de passe root
SHW
24
POURQUOI avez -vous besoin sudode ces utilisateurs? Si vous ne leur faites pas confiance, ne leur donnez pas sudoaccès en premier lieu. Notez également que, dans l'idéal, root ne devrait pas du tout avoir de mot de passe , mais que vous devriez utiliser d'autres moyens d'authentification. (Que l'utilisateur pourra toujours "pirater", même si vous voulez protext /etc/passwd)
Anony-Mousse
3
Qu'est-ce que ces utilisateurs doivent faire exactement?
Olivier Dulac
4
Que vont-ils faire avec leurs privilèges root? Il pourrait y avoir une meilleure solution que ce que vous pensez.
sparticvs
23
C’est un de ces "Dieu peut-il faire un rocher si grand qu’il ne peut pas le soulever lui-même?" tapez des questions. Si vous avez un accès root, vous pouvez faire n'importe quoi, c'est pourquoi il est préférable de donner un accès root de manière judicieuse. sudoet setuidpeut résoudre la plupart des problèmes.
bsd

Réponses:

57

Nous voulons que certains utilisateurs puissent faire par exemple sudoet devenir root,

Eh bien, c’est le problème que sudo est conçu pour résoudre, de sorte que cette partie est assez simple.

mais avec la restriction que l'utilisateur ne peut pas changer le mot de passe root.

Comme SHW l'a souligné dans un commentaire, vous pouvez configurer sudo pour autoriser uniquement certaines actions à être effectuées en tant que root par certains utilisateurs. Autrement dit, vous pouvez autoriser l'utilisateur1 à faire sudo services apache2 restart, autoriser l'utilisateur2 à faire, sudo rebootmais rien d'autre, tout en autorisant l'administrateur recruté en tant qu'administrateur système user3à le faire sudo -i. Il y a des howtos disponibles sur la façon de configurer sudo comme ça, ou vous pouvez chercher (ou demander) ici. C'est un problème qui peut être résolu.

Cependant, un utilisateur qui a été accordé la possibilité de sudo -iou sudodans une coquille ( sudo bashpar exemple) peut faire quoi que ce soit. En effet, à l'heure où sudo lance le shell, sudo n'est plus sur la photo. Il fournit le contexte de sécurité d'un utilisateur différent (le plus souvent root), mais n'a aucun mot à dire sur ce que fait l'application exécutée. Si cette application passwd rootest lancée à son tour , rien ne peut être fait par sudo. Notez que cela peut aussi être fait par d’autres applications; Par exemple, de nombreux éditeurs plus avancés fournissent des fonctionnalités permettant d'exécuter une commande via le shell, un shell qui sera exécuté avec l'identifiant effectif de ce processus d'édition (c'est-à-dire, root).

C’est-à-dire que nous pouvons toujours nous connecter à ce serveur et devenir root, quoi que fassent les autres utilisateurs.

Pardon; si vous voulez vraiment dire "assurez-vous que nous pourrons nous connecter et utiliser le système peu importe ce que quelqu'un avec un accès root y fait", cela (à toutes fins pratiques) ne peut être fait. Un rapide "sudo rm / etc / passwd" ou "sudo chmod -x / bin / bash" (ou tout ce que la racine du shell utilise) et vous êtes quand même assez arrosé. "Assez arraché", ce qui signifie "vous aurez besoin de restaurer à partir d'une sauvegarde en espérant qu'ils n'ont rien fait de pire qu'un glissement de doigts". Vous pouvez prendre certaines mesures pour réduire le risque d' accident accidentel conduisant à un système inutilisable, mais vous ne pouvez pas empêcher la malveillance de causer de très graves problèmes pouvant aller jusqu'au besoin de reconstruire le système à partir de zéro ou à tout le moins de problèmes connus. bonnes sauvegardes.

En accordant à un utilisateur un accès root sans entrave sur un système, vous faites en sorte que cet utilisateur (y compris tout logiciel qu’il pourrait choisir d’exécuter, même quelque chose d'aussi banal que ls) ne soit pas victime d'intention malveillante et ne se trompe pas accidentellement. C'est la nature de l'accès root.

Un accès root limité, par exemple sudo, est un peu mieux, mais vous devez toujours faire attention à ne pas ouvrir de vecteurs d'attaque. Et avec l'accès root, il existe de nombreux vecteurs d'attaque possibles pour les attaques avec élévation de privilèges.

Si vous ne pouvez pas leur faire confiance avec le niveau d'accès qu'implique la racine, vous aurez besoin d'une configuration sudo très stricte ou simplement de ne pas accorder à l'utilisateur en question un accès root par quelque moyen que ce soit, que ce soit par sudo ou autrement.

un CVn
la source
3
Je suis désolé ma réponse a eu tout le battage médiatique (je ne comprends pas tout à fait!). Votre réponse soulève d’excellents points et j’espère qu’elle sera acceptée. +1 à vous, monsieur.
Joseph R.
@JosephR. Parfois, une réponse concise est préférable.
David Cowden
@ DavidCowden Ouais, il semble que ce soit le cas ici ...
Joseph R.
1
@JosephR. Pas de soucis pour moi. La communauté Stack Exchange n'est pas toujours prévisible, et les questions qui ont déjà reçu beaucoup de votes positifs ont tendance à en attirer davantage. Merci pour le vote positif, cependant. :)
un CVn
92

C'est pratiquement impossible. Tout d’abord, si vous leur accordez le pouvoir de devenir racine , vous ne pouvez rien faire pour les empêcher de faire quoi que ce soit. Dans votre cas d'utilisation, sudovous devez utiliser pour octroyer à vos utilisateurs des pouvoirs de root tout en restreignant l'accès des autres sans leur permettre de devenir root .

Dans votre scénario, vous devez restreindre l' accès aux suet passwdcommandes et l' accès ouvert à peu près tout le reste. Le problème, c'est que vous ne pouvez rien faire pour empêcher vos utilisateurs de modifier /etc/shadow(ou /etc/sudoersd'ailleurs) directement et de placer un mot de passe root de remplacement pour pirater la racine. Et ce n'est que le scénario "d'attaque" le plus simple possible. Les Sudoers avec une puissance illimitée, à l'exception d'une ou deux commandes, peuvent contourner les restrictions pour détourner l'accès root complet.

La seule solution, suggérée par SHW dans les commentaires, consiste sudoà autoriser vos utilisateurs à accéder à un ensemble de commandes restreint.


Mise à jour

Il existe peut-être un moyen d'y parvenir si vous utilisez des tickets Kerberos pour l'authentification. Lisez ce document expliquant l’utilisation du .k5loginfichier.

Je cite les parties pertinentes:

Supposons que l'utilisateur alice ait un fichier .k5login dans son répertoire personnel contenant la ligne suivante:
[email protected]
Cela permettrait à bob d'utiliser les applications réseau Kerberos, telles que ssh (1), pour accéder au compte d'alice à l'aide des tickets Kerberos de bob.
...
Notez que, étant donné que Bob conserve les tickets Kerberos pour son propre mandant, [email protected]il ne dispose d'aucun des privilèges nécessitant des tickets d'alice, tels que l'accès root à l'un des hôtes du site ou la possibilité de changer le mot de passe d'alice.

Je pourrais me tromper, cependant. Je suis toujours en train de parcourir la documentation et je n'ai pas encore essayé Kerberos pour moi-même.

Joseph R.
la source
Comment avez-vous fait cette référence cool à un commentaire? J'ai regardé la source de votre réponse et j'ai vu () l'entourer. Cool chapeau secret!
Joe
@ Joe Le temps qu'un commentaire a été posté est en fait un lien vers le commentaire lui-même.
Joseph R.
@Joe Trouvez l'id ( <tr id="thisistheid"...) du commentaire (par exemple, dans Chrome, cliquez avec le bouton droit de la souris sur et Inspect element), puis ajoutez-le au lien de fil avec le précédent #. Dans votre cas (id = comment-162798), cela ressemble à ceci: unix.stackexchange.com/questions/105346/…
polym
1
Merci pour la réponse, je ne savais pas si je devais accepter ceci ou cela de Kjörling @ Michael, j'ai choisi parce que cela a son description plus - besoin d'un noob comme moi :) Cependant, le vôtre a également été utile
244an
@ 244an Pas de soucis. J'aurais recommandé la même chose moi-même. :)
Joseph R.
17

Je suppose que vous voulez vous assurer que vous avez un accès "administrateur d'urgence", même si votre administrateur actuel est foutu (mais à part cela, vous faites entièrement confiance à l'administrateur principal).

Une approche populaire (bien que très furtive) consiste à avoir un deuxième utilisateuruid=0 , communément nommé toor(racine inversée). Il a un mot de passe différent et peut servir d'accès de sauvegarde. Pour ajouter, vous devrez probablement éditer /etc/passwdet /etc/shadow(copier les rootlignes).

C'est presque sûr, mais si vous avez juste besoin de vous protéger contre "l'administrateur principal" qui change le mot de passe sans préavis, cela fonctionnera. Il est facile de désactiver, en supprimant le toorcompte; le seul avantage est donc d'avoir un mot de passe séparé.

Vous pouvez également rechercher d'autres mécanismes d'authentification, tels que les sshclés libnss-extrausers, LDAP, etc.

Notez que l’administrateur peut encore tout gâcher. Par exemple, en bloquant le pare-feu.

Si vous voulez avoir un système très sécurisé, envisagez d’utiliser SELinux, où l’utilisateur unix (par exemple, root) aura également un rôle, qui peut être beaucoup plus détaillé. Vous voudrez peut-être donner à votre administrateur un accès root, mais uniquement un rôle restreint (par exemple, administrer Apache uniquement). Mais cela nécessitera beaucoup d'efforts de votre part pour configurer correctement la stratégie.

Anony-Mousse
la source
6
Cela n'empêche pas l'utilisateur toorde changer le mot de passe root; il ne fournit qu'un deuxième mot de passe pour devenir root avec.
alexis
2
-1, alors. Vous suggérez un mot de passe de porte dérobée pour que les administrateurs puissent récupérer l'accès root après l'avoir perdu ??? C’est tout bête, et à part les utilisateurs gênants, vous pouvez facilement le désactiver, comme vous le dites. Il existe des moyens beaucoup plus fiables pour configurer une porte dérobée.
alexis
2
@ alexis C'est ce que IMHO l'auteur de la question demandée. Pourquoi donner -1 pour cela? toorLes comptes de recouvrement sont une pratique courante (bien que mal vue) sur Unix depuis des décennies.
Anony-Mousse
9
Si le seul objectif est d'empêcher toute modification accidentelle du mot de passe, c'est une bonne réponse. Si l'objectif est d'empêcher quoi que ce soit de malveillant, cela ne vous aidera pas beaucoup. Comme le PO n'a pas précisé l'objectif, nous ne le savons pas.
Bobson
2
C’est la raison pour laquelle j’ai déclaré que dans ma première phrase: "bousillez ... à part ça, vous avez confiance ... à fond". Il s’agit en réalité uniquement d’une solution "d’accès au support"; pas un élément de sécurité. L'utilisation de clés ssh supplémentaires permet d'obtenir le même résultat, sans être trop malicieux.
Anony-Mousse
11

L'essence de la racine est d'avoir une maîtrise sans restriction du système. Vous pouvez le modifier avec SELinux (il existait un site de démonstration sur lequel tout le monde pouvait se connecter en tant que root, mais sa puissance était paralysée par le système d'accès), mais ce n'est pas le but. Le fait est que c'est la mauvaise solution à votre problème.

Maintenant, vous n'avez pas dit quel était votre problème, mais si vous ne faites pas confiance à ces utilisateurs pour ne pas toucher le mot de passe root, ils n'ont rien à faire à être root. S'ils ont besoin d'administrer le serveur Web, ou divers périphériques matériels, ou le lecteur de warp ou autre, configurez une solution à cet effet. Créez un groupe super puissant, donnez-lui tous les accès dont il a besoin et ajoutez-les-lui. S'ils ont besoin d'exécuter des appels système uniquement root, écrivez quelques programmes setuid.

Bien sûr, un utilisateur avec ce type d'accès (et un peu de connaissance) pourrait probablement facilement pirater le système, mais au moins, vous travaillez avec le modèle de sécurité du système d'exploitation, et non contre celui-ci.

PS Il existe de nombreuses façons d’organiser l’accès root sans mot de passe. Pour commencer, si vous êtes sur place /etc/sudoers(sans restrictions), vous n'avez besoin que de votre propre mot de passe pour devenir root, par exemple avec sudo bash. Mais vous ne devriez tout simplement pas avoir besoin d'y aller.

alexis
la source
Mais le problème est que vous ne pouvez pas empêcher l'attaquant de prendre racine grâce à un exploit, SELinux fournit une défense en profondeur.
Timothy Leung
11

Il est probablement possible, du moins en théorie, de faire cela avec SELinux . Cela vous permet de définir des règles beaucoup plus précises sur ce qu'un utilisateur ou un processus est autorisé ou non à faire. Même avec SELinux, il peut s'avérer difficile d'empêcher un utilisateur de modifier le mot de passe root, tout en lui permettant de faire tout ce dont il a besoin.

Cela dépend vraiment de ce que l'utilisateur qui n'est pas autorisé à modifier le mot de passe root doit pouvoir faire. Il serait probablement plus facile et plus sûr de simplement déterminer ce dont il s'agit et d'accorder ces autorisations spécifiquement à l'aide de sudo.

Rjmunro
la source
8
Cela peut théoriquement être possible de faire cela avec SELinux (et je ne suis pas convaincu), prétendre que le fait de ne pas montrer de règles réelles ne va aider personne.
Gilles, arrête de faire le mal
@ Gilles bien en fait , c'est pour cela que SELinux a été conçu. SELinux est une couche d'autorisations requise en plus des autorisations POSIX standard. Sur un ordinateur SELinux correctement configuré, l’accès root n’a pas de sens puisque vos vraies autorisations sont déterminées par le contexte de sécurité et le libellé de l’objet.
tylerl
2
Si vous savez comment le faire, veuillez répondre Mythe ou réalité: SELinux peut-il limiter l'utilisateur root?
Gilles 'SO- arrête d'être méchant'
Théoriquement, cela peut toujours être faisable avec SELinux; Toutefois, la configuration de ce type de configuration devrait être plus complexe, afin de garantir une séparation robuste de TOUS les fichiers de configuration liés à SELinux du système de fichiers "normal" (auquel l' rootutilisateur dispose d'un accès complet). En fin de compte, la méthode "la plus facile" pour une telle séparation (avec ou sans SELinux) consisterait à utiliser quelque chose comme Kerberos, comme mentionné par Joseph R.
ILMostro_7
7

Peut-être devriez-vous envisager de laisser aux utilisateurs un accès root à une machine virtuelle ou à un conteneur LXC. Cela leur permettrait d'avoir un accès root complet à un système, sans leur empêcher de vous connecter à l'hôte ou de prendre des mesures administratives.

DSimon
la source
Ce serait plus sûr que la plupart des options IMHO.
Elder Geek
5

Je ne sais pas si cela sera réalisable dans la pratique, mais voici un sale bidouillage:

  1. écrivez un script / programme wrapper qui copiera le /etc/passwdfichier dans un autre emplacement, avant d’appelersudo
  2. Autoriser l'utilisateur normal à utiliser sudo
  3. Une fois sa tâche terminée ou à la sortie de sudo, restaurez le /etc/passwdfichier.

Je sais, il y a beaucoup de choses plus-moins que vous devez considérer pour atteindre cet objectif. Après tout, c'est un sale coup

SHW
la source
3
Il est toujours possible qu'un utilisateur malveillant lise ce script et cloue la copie de sauvegarde.
Joseph R.
C'est aussi à peu près ce vipwque font déjà les amis.
un CVn
Considérez-le comme un programme et n’ayant qu’un accès root
SHW
1
rootpeut éditer "l'autre emplacement" après sudo.
Anony-Mousse
5
Pourquoi voudriez-vous ACCÉDER un accès root à un utilisateur potentiellement malveillant ??? En tant que root, il est trivial d'installer une porte dérobée qui ne dépende pas de la traversée de sudo et / ou de l'emballage ...
alexis
5

La déclaration qui sudoest juste pour accorder la racine et il n'y a pas de protection après cela est manifestement fausse.

Vous utilisez visudopour modifier le fichier sudoers. Voici un exemple de ligne:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command
  • redsandroest le nom d'utilisateur que nous donnons la permission. Mettez un %à l'avant pour le faire appliquer à un groupe.
  • ALLest un nom pour cette règle. Les Sudoers peuvent faire beaucoup plus que simplement accorder des autorisations globales. C'est là que ça se complique cependant.
  • = n'a pas besoin d'explication
  • ALL:ALLse lit comme suit (who_to_run_it_as: what_group_to_run_it_as). De cette façon, vous pouvez autoriser l'exécution d'une commande, mais uniquement dans le contexte d'un utilisateur ou d'un groupe spécifique.
  • NOPASSWD: lui dit de désactiver l'invite de mot de passe.
  • /path/to/command vous permet de spécifier des commandes spécifiques path_to_commmand, une autre_command

Il est important de rappeler que si les utilisateurs sudoparticuliers l'utilisent principalement pour accéder aux privilèges root, ils peuvent et sont utilisés pour contrôler l'accès à des commandes spécifiques de manière beaucoup plus granulaire.

Références

  • de mon autre réponse ici
RobotHumans
la source
Cette réponse explique comment configurer sudo pour un accès root limité, mais il serait beaucoup mieux que la réponse le dise et où cela devrait aller.
un CVn
@ MichaelKjörling terminé
RobotHumans
3
"L'affirmation selon laquelle sudo concerne uniquement l'octroi de root et qu'il n'y a plus de protection après cela est manifestement fausse." Supposons que j'accorde l' sudo viaccès à un utilisateur parce que je veux qu'il puisse modifier les fichiers de configuration du système. Cet utilisateur effectue ensuite :!/bin/bashune sudo visession. Comment la capacité de sudo à limiter les commandes qu'un utilisateur peut exécuter via sudo aide-t-elle à protéger mon système dans ces circonstances? (Personne n'a dit que sudo ne pouvait pas être configuré plus étroitement qu'une sudo -iapproche du tout ou rien .)
a CVn
6
Comprendre les limites d'une approche est facilement aussi important que savoir effectuer une tâche.
un CVn
1
@ MichaelKjörling, je pense que ce n'est qu'un exemple. Mais pour être clair, la bonne façon de laisser les utilisateurs éditer des fichiers de configuration système est de les laisser s'exécuter sudoedit. Vous pouvez spécifiquement identifier quels fichiers ils devraient pouvoir sudoedit. C'est dans man sudoers.
Matthew Flaschen
3

(Je ne connais pas Ubuntu, mais cela devrait ressembler à Fedora / Red-Hat)
La seule chose que je peux imaginer restreindre l'accès à la modification du mot de passe root n'est pas un accès root complet, peut-être avec sudo, ou l'utilisation de SElinux pour restreindre l'accès. au fichier de mots de passe ... mais je ne ferais pas confiance à beaucoup d'accès car root a généralement un accès illimité et pourrait mettre à jour SElinux, ou renommer le fichier de mots de passe, ou exécuter un programme pré-préparé pour changer le mot de passe.

Si vous ne leur faites pas suffisamment confiance pour ne pas changer le mot de passe, vous ne devriez probablement pas leur donner d'accès root. Sinon, je suppose que vous essayez d'éviter les accidents.

Si vous essayez uniquement de protéger votre accès à root, configurez un programme capable de restaurer le mot de passe root. Ainsi, même s'il a été modifié, il peut être restauré avec un accès minimal. (sudo fait bien tout seul)

9mjb
la source
3

Votre exigence est:

Nous avons un petit problème sur un serveur, c'est-à-dire une [...] garantie que nous pouvons toujours nous connecter à ce serveur et devenir root, quoi que fassent les autres utilisateurs.

D'après votre question, il semble que vous ne soyez pas confronté à des utilisateurs malveillants aléatoires cherchant à détruire votre système, mais à des utilisateurs semi-fiables qui peuvent causer des méfaits de temps en temps (étudiants peut-être?). Mes suggestions visent cette situation et non un assaut total d'utilisateurs malveillants.

  1. Exécutez le serveur dans un environnement virtuel. Vous pourrez monter le système de fichiers du serveur et remplacer les fichiers modifiés par des versions dont l'état sera connu. Selon les dommages possibles que vous prévoyez, vous pouvez prendre un instantané de tous les répertoires critiques (/ bin, / sbin, / etc, / usr, / var, etc.) et développer l’instantané pour écraser les fichiers endommagés tout en laissant le reste de la liste. système intact.

  2. Exécutez le système en lecture seule, par exemple à partir d'un DVD-R. Si vous pouvez vivre avec la plupart des parties du système statiques jusqu'au prochain redémarrage, c'est une bonne option. Vous pouvez également utiliser un magasin de support en lecture seule avec un environnement virtuel ou charger le système de base sur le réseau, ce qui facilite beaucoup les modifications entre les redémarrages par rapport à l’écriture d’un nouveau DVD-R.

  3. Modules du noyau. Les modules de sécurité Linux du noyau (LSM) constituent la base de la création de modules sécurisés. LSM est utilisé par SELinux, mais également par un certain nombre de systèmes moins connus et plus simples, tels que Smack, TOMOYO et AppArmor. Cet article a un bon aperçu des options. Il est fort probable que l'une de celles-ci puisse être configurée telle quelle pour empêcher l'accès en écriture à / etc / passwd, à / etc / shadow ou à tout autre fichier de votre choix, même à la racine.

  4. Même idée que n ° 1, mais lorsque le serveur n'est pas dans un environnement virtuel. Le serveur peut être chargé en chaîne dans un système d'exploitation en lecture seule, tel qu'un CD dynamique, qui monte automatiquement le système de fichiers du serveur et écrase le système de base à chaque démarrage avec des copies dont l'état est connu. Le système d'exploitation en lecture seule devrait alors démarrer dans le système d'exploitation principal.

  5. Encore une fois, s’il s’agit d’utilisateurs semi-dignes de confiance qui sont responsables devant un supérieur (enseignant / patron), la meilleure réponse pourrait être Linux Audit . De cette façon, vous saurez toutes les actions entreprises en matière de sécurité et qui les a entreprises (vous saurez qui les a prises car même si tous les utilisateurs partagent le compte root, ils auront d'abord quitté leur compte utilisateur). En fait, vous pourrez même analyser le journal d'audit en temps réel et remplacer les fichiers endommagés. / etc / shadow écrasé? Pas de problème, il suffit que le serveur de surveillance le remplace instantanément par une version en bon état.

Autres technologies que vous pouvez explorer en fonction de vos besoins:

Animisme
la source
2

Pour compléter les autres réponses, je vais supposer que le scénario est que vous percevez que perdre le contrôle de root est une situation rare et que, dans ces cas, un redémarrage du serveur est autorisé. (Après tout, si vous pensez que la machine a été compromise, vous voudrez quand même la déconnecter.)

Le grand avantage de ceci est qu'il n'y a rien à configurer. Votre question devient: " J'ai oublié le mot de passe root, comment puis-je y revenir? " Et la réponse à cela est de redémarrer l'ordinateur, puis de choisir le mode mono-utilisateur lorsque la machine est activée. Cela vous donne un shell root sans avoir besoin de connaître le mot de passe. À ce stade, vous pouvez définir un nouveau mot de passe. (Ainsi que réparer les dégâts éventuels ...)

Darren Cook
la source
2
Comme l’a si bien fait remarquer Michael , un utilisateur malveillant peut empêcher l’accès à la racine sans nécessairement détourner le mot de passe en faisant simplement fuir les fichiers binaires. Même l' init=...approche peut être empêchée de supprimer les autorisations d'exécution des fichiers binaires pertinents. Je pense qu'une meilleure solution dans ce cas consiste à monter votre système de fichiers racine via LiveCD et (essayer de) réparer les dégâts. Encore une fois, si vous pensez que le système a été compromis, il vaut mieux restaurer de toute façon à partir d’une sauvegarde.
Joseph R.
Convenu @JosephR; La découverte et la réparation des dommages sont compliquées, et je réinstalle simplement aussi. Mais j'imagine que l'inquiétude du PO concernait davantage le fait que quelqu'un l'ait bloqué accidentellement ... délibérément, piratage informatique au travail ou à l'école est un peu suicidaire. ;-)
Darren Cook
1
Pas nécessairement. Un utilisateur vraiment malveillant associé à un administrateur système insouciant / désemparé peut élever ses privilèges sans être détecté. Je conviens que l'intention initiale du PO était probablement de parer aux erreurs innocentes plutôt que de se prémunir contre les intentions malveillantes, mais la question portait la mention "sécurité" et nous nous en sommes contentés, je suppose :)
Joseph R.
2

Si vous cloner votre serveur dans une machine virtuelle (comme VirtualBox ), vous pouvez donner un accès root sans entraves aux personnes et garantir encore que vous aurez toujours accès direct à la partition du système d'exploitation invité (s), et donc de maintenir le contrôle final sur /etc/passwdet le même, puisque vous aurez la racine sur le système hôte.

Bien sûr, l’octroi d’un accès root sans entrave n’est peut-être toujours pas la bonne solution: si la sécurité des données est un problème ou relève de votre responsabilité, vous ne pouvez pas céder l’accès root.

SevenSidedDie
la source
2

L'exigence n'est pas techniquement possible. Comme déjà commenté avec éloquence, accorder des sudodroits illimités, voire plus limités , à un utilisateur signifie que vous avez confiance en cet utilisateur. Quelqu'un qui a de mauvaises intentions, suffisamment de technique et de persévérance peut passer par tous les obstacles mis en place.

Cependant, en supposant que vous pouvez faire confiance à vos utilisateurs de ne pas être mal intentionné, vous pouvez faire la restriction sur le mot de passe de changer une question de politique . Vous pouvez créer un wrapper pour passwdprogramme qui leur rappellera "s'il vous plaît, ne changez pas le mot de passe root". Cela suppose que la source du problème est que les utilisateurs qui modifient le mot de passe root le font en raison d'un malentendu (par exemple, ils pensent peut-être qu'ils modifient leur propre mot de passe après l'avoir fait sudo bash).

Dans des circonstances spéciales (rares), si une confiance totale n'est pas possible et s'il est impossible de casser l' sudoaccès à des fragments adéquats mais raisonnablement sûrs, vous pouvez envisager de définir des sanctions organisationnelles contre le changement de mot de passe (ou toute autre forme spécifiée de falsification du système). surveillance des ressources critiques afin qu'il ne soit pas facile de passer inaperçu pour contourner les règles définies - et d'être public et transparent en ce qui concerne les règles d'utilisation et la surveillance.

L’aspect surveillance et découverte est un problème technique difficile qui profite d’une autre question si vous choisissez de suivre cette voie. Il me semble que nous aurions besoin de

  1. détecter quand un utilisateur change d'identité en root et suivre tous les processus créés;
  2. enregistrez les créations de processus à partir de là pour voir qui est l'utilisateur d'origine responsable de chaque processus, et en utilisant un hôte distant où les utilisateurs à moitié confiance n'ont pas accès pour envoyer les journaux;
  3. utilisez une sorte de système de traçage pour consigner ce qui se passe et pour pouvoir découvrir plus tard qui était à l'origine de la violation de la politique.

Nous aurions au moins besoin de consigner l'ouverture de session pour un ensemble de fichiers autre que sûr pour l'écriture, la création de processus exec()et, bien sûr, toute tentative de modification du réseau.

L'implémentation pourrait être réalisée par la libc modifiée ou (bien mieux) le traçage des appels système.

Bien sûr, il est impossible de faire fonctionner ce traçage et cette journalisation à 100% correctement, sa mise en œuvre est difficile et elle nécessite également des ressources supplémentaires pour fonctionner. Ce ne serait pas arrêter le changement de mot de passe ou un autre système indésirable falsification, mais il rendrait (plus probable) possible de trouver l'utilisateur coupable ou au moins créer une illusion qu'il est suivi et le rendre moins invitant pour certains utilisateurs mal d' esprit (mais Certains hackers épris de problèmes qui voient la futilité fondamentale des mesures techniques mises en place pourraient se sentir encouragés à relever le défi et à essayer de contourner le système juste pour le plaisir.

FooF
la source
1

La question initialement formulée est inutile. Il semble que l’objectif principal soit «d’avoir encore un identifiant», aussi parlons-nous d’une entrée d’urgence qui continue de fonctionner avec certitude même avec un accès root accordé à une autre personne. Bravo à Anony-Mousse qui l'a noté explicitement pour la première fois.

Le problème est le suivant: si le propriétaire a un accès physique à la boîte, il peut facilement récupérer des accès logiques au système (à condition qu’il soit toujours actif :). Si ce n'est pas le cas, le fait de conserver le mot de passe root ne résoudra pas, par exemple, l'installation de sshd down ou de mauvais réseaux, de sorte que le système n'est toujours pas accessible.

La question de savoir comment empêcher le système d’être endommagé par une personne disposant de privilèges d’administrateur semble trop vaste pour convenir au format de question SE.

En ce qui concerne la solution d’entrée d’urgence à distance, le meilleur moyen est IPMI (je pense) si elle est disponible. Le propriétaire du système peut attacher un lecteur virtuel à tout moment, démarrer à partir de celui-ci et procéder à la récupération du système.

Si IPMI n'est pas disponible, toute technologie de virtualisation appropriée peut être contournée, comme cela a déjà été proposé ci-dessus.

Veniamin
la source
0

Vous pouvez limiter l'accès à sudo dans votre /etc/sudoersfichier

Pour expliquer complètement la syntaxe de / etc / sudoers, nous allons utiliser un exemple de règle et décomposer chaque colonne:

jorge  ALL=(root) /usr/bin/find, /bin/rm

La première colonne définit à quel utilisateur ou groupe cette règle sudo s'applique. Dans ce cas, c'est l'utilisateur jorge. Si le mot dans cette colonne est précédé d'un symbole%, il désigne cette valeur comme un groupe plutôt que comme un utilisateur, puisqu'un système peut avoir des utilisateurs et des groupes du même nom.

La deuxième valeur (ALL) définit les hôtes auxquels cette règle sudo s'applique. Cette colonne est particulièrement utile lorsque vous déployez un environnement sudo sur plusieurs systèmes. Pour un système Ubuntu de bureau ou pour lequel vous ne prévoyez pas de déployer les rôles sudo sur plusieurs systèmes, vous pouvez laisser cette valeur définie sur ALL, qui est un caractère générique qui correspond à tous les hôtes.

La troisième valeur est définie entre parenthèses et définit l'utilisateur ou les utilisateurs avec lesquels l'utilisateur de la première colonne peut exécuter une commande. Cette valeur est définie sur root, ce qui signifie que jorge sera autorisé à exécuter les commandes spécifiées dans la dernière colonne en tant qu'utilisateur root. Cette valeur peut également être définie sur le caractère générique ALL, ce qui permettrait à Jorge d'exécuter les commandes en tant qu'utilisateur du système.

La dernière valeur (/ usr / bin / find, / bin / rm) est une liste de commandes, séparées par des virgules, que l'utilisateur de la première colonne peut exécuter en tant qu'utilisateur (s) de la troisième colonne. Dans ce cas, nous autorisons jorge à exécuter find et rm en tant que root. Cette valeur peut également être définie sur le caractère générique ALL, ce qui permettrait à Jorge d'exécuter toutes les commandes du système en tant que root.

En gardant cela à l’esprit, vous pouvez autoriser les commandes X de manière délimitée par des virgules et tant que vous n’ajoutez rien, passwdcela devrait aller.

ehime
la source
-1

Il n'y a pas 1/2 racine :) Une fois que vous avez accordé les privilèges root, ils peuvent faire ce qu'ils veulent. Vous pouvez également utiliser sudo pour exécuter un shell bash restreint ou exécuter rbash sans privilèges root.

Si vous souhaitez disposer d'un mécanisme de sécurité intégrée pour vous connecter au serveur en tant que root, vous pouvez créer un autre utilisateur uid=0ou créer un simple cron qui réinitialisera périodiquement le mot de passe root.

Martin
la source
Il est facile de s’échapper d’une bash restreinte, voir ce blog Sans
Franklin Piat
-1

Essayez d’ajouter un groupe de roues plutôt que d’utiliser sudo. sudo permet à un utilisateur de s'exécuter comme s'il était root, ce qui signifie que ce n'est pas différent de l'exécution:

su -

devenir racine. La racine uid = 0; la roue uid = 10. Les gens utilisent les noms mais le système d'exploitation utilise l'ID. Certaines commandes ne peuvent pas être exécutées par un membre du groupe Wheel. (Si vous utilisez wheel, ne faites pas l'erreur d'ajouter la racine en tant que membre du groupe de roues). Consultez la documentation Red Hat si vous ne savez pas ce que la roue est.

Une autre option consiste à utiliser une clé ssh plutôt qu'un mot de passe. En supposant que vous puissiez être sûr que les utilisateurs de sudo n’ajouteront pas leurs clés publiques au fichier ~ / .ssh / allowedkeys, cela résoudra le problème de la modification du mot de passe root car celui-ci est ignoré.

Si vous préférez éviter d’étendre la confiance à ces utilisateurs (sans ajouter leur propre clé publique), essayez d’utiliser des attributs de fichier étendus et le bit Immutable. Après avoir créé votre fichier ~ / .ssh / allowedkeys et après avoir configuré les fichiers / etc / ssh / sshd_config et / etc / ssh / ssh_config à votre guise, définissez le bit Immutable. Bien sûr, il existe des moyens de visser avec cela aussi - rien n'est parfait.

Dans tout système, les initiés sont le risque le plus élevé. La personne qui dirige le spectacle est au sommet de la pile. Une pensée connexe concerne les contrats. Les avocats vous diront: "Ne faites jamais affaire avec quelqu'un pour qui vous avez besoin d'un contrat". Le bon sens nous dit: "Ne faites jamais affaire sans contrat". Lorsque vous trouvez quelqu'un en qui vous avez assez confiance pour faire affaire avec vous, rédigez le contrat en fonction des besoins de chacun.

Toutes les réponses soumises, y compris la mienne, n'abordent pas l'accès physique. Celui qui en a le contrôle. Si ce n'est pas votre cas, vous avez probablement le moyen de demander à la personne qui le fait d'accéder physiquement à la machine si quelqu'un trouve un moyen de vous empêcher de vous connecter, ou s'il trouve un moyen de vous connecter même après vous. 'ont essayé d'empêcher que cela se produise. Bien sûr, si vous avez un accès physique, aucune de ces choses ne sera peut-être nécessaire, mais la mise en place d'un couple devrait de toute façon être envisagée, si vous êtes intéressé à ne PAS être dérangé.

-John Crout

John Crout
la source
sudoest extrêmement différent de su -. Cela a été souligné à maintes reprises, par exemple par SHW , Joseph R. , moi - même , hbdgaf et peut-être plusieurs autres. Le champ de commentaire est trop court pour inclure ...
un CVn
Tout à fait vrai, mais hors de propos. Vous discutez d'autres moyens de devenir root et des risques liés à l'octroi d'un accès root, mais rien qui ait une incidence sur «l'accès root qui ne peut pas changer le mot de passe root».
Gilles, arrête de faire le mal '17
Vrai. La question est un oxymoron logique; Il ne peut exister que si l'installation est cassée. À quoi sert un compte / login d'utilisateur où cet utilisateur ne peut pas changer son mot de passe alors qu'il a un accès root? Par conséquent, les suggestions proposées s’appliquent à ce que l’interrogateur a pu vouloir dire; pas à la façon dont ils ont écrit la question. Toute méthode de contrôle d'accès comporte un risque inhérent.
John Crout
-3

Une solution serait de s’assurer que ce /etcn’est pas accessible en écriture. Par personne, tant qu'il pourrait y avoir un sudoerautour.

Cela pourrait être fait en le montant sur le réseau et en veillant à ce que le périphérique ne puisse pas être écrit.

Cela pourrait être fait en utilisant un périphérique local qui empêche l'accès en écriture à celui-ci. (Rechercher le write blockermatériel)

La partie importante est que la restriction doit s'appliquer en dehors du concept de base de cette machine. Un pirate informatique créatif trouvera son chemin autour de tous les obstacles que vous les placerez dans l'environnement qu'il pourrait contrôler. Donc si root peut changer son mot de passe, alors un sudoer.

Pour être certain que l'utilisateur ne peut pas non plus bousiller vos capacités de connexion, vous devez avoir monté en lecture seule /binet /sbin.

Et vous devrez avoir un script qui restaure périodiquement la connexion réseau.

(En remarque: si vous n'autorisez le sudoer qu'à un ensemble très limité de commandes et que chacune d'entre elles est sûre de ne pas pouvoir les remplacer / les remplacer, etc., vous pouvez empêcher son exécution en /etcécriture.)

Angelo Fuchs
la source
Monter / etc en lecture seule, même s'il est peut-être possible (par exemple, vous devez être prudent lors de l'installation de la racine du pivot) dans les scripts de démarrage d'initrd, risque d'être une installation plutôt fragile. De plus, un utilisateur avec un accès root peut faire beaucoup de choses qui empêchent les autres utilisateurs d’obtenir les privilèges root sans impliquer de modifications dans / etc.
un CVn
@ MichaelKjörling La configuration n'est pas fragile, je l'utilise souvent (comme montages locaux en lecture seule).
Angelo Fuchs
@ MichaelKjörling J'ai ajouté d'autres éléments que vous voudrez avoir en lecture seule si vous voulez vous assurer que vous pouvez toujours vous connecter. Ainsi, la liste des actions à effectuer si vous vous engagez dans cette voie n'est pas si courte, mais c’est la seule façon "de garantir que nous pourrons toujours nous connecter à ce serveur et devenir root, quoi que fassent les autres utilisateurs."
Angelo Fuchs
J'admets que je n'ai jamais vu la nécessité de l'essayer, mais une chose que je peux vraiment voir qui serait risquée est la façon dont init va gérer le remplacement de / etc / inittab sous ses pieds. Ou ce que le système fera si le fichier initial / après montage / etc / fstab est différent. Et il y a / etc / mtab. D'autres utilisateurs peuvent vouloir changer leurs propres mots de passe, ce qui implique d'écrire dans / etc / shadow et éventuellement dans / etc / passwd. Et monter / etc en lecture seule n’est encore qu’une solution partielle. Je ne dis pas que cela ne peut pas faire partie d'une solution, mais ce n'est certainement pas la première étape que je franchirais dans la situation du PO.
un CVn
1
Oui. Cela est dangereux et pose de graves problèmes s’il est mal fait. Pour autant que je sache, c’est le seul moyen viable de résoudre la demande de PO pour les utilisateurs qui devraient être autorisés à devenir root.
Angelo Fuchs