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?

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.

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:
bob@FOOBAR.ORG
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, bob@FOOBAR.ORGil 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.

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.

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.

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.

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.

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

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

(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)

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:

• Architecture de mesure d'intégrité Linux / Module de vérification étendue (IMA / EVM), et
• Modules de plate-forme sécurisée (TPM).

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 ...)

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.

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.

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.

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.

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.

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

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.)