Journal Administrateurs, Sécurité et NFS

Posté par bobert le 23 avril 2004 à 10:00.

Étiquettes : aucune

avr.

2004

Allez, tiens, ce sera mon coup de gueule du jour, ça me fera du bien.

Dans les deux labos où je bosse, et dans beaucoup d'autres autour de moi, il y a à la fois:
- des données utilisateurs centralisées sur un serveur et partagées par NFS
- des administrateurs, chevaliers des temps modernes en guerre permanente contre les méchantes failles de Sécurité

Bon. Y'a quelques temps, avec l'accord des admins, je mets à jour la distrib de mon poste au boulot et je découvre ce qui me paraît être une faille (ou un trou, enfin je laisse aux susdits chevaliers le choix du terme exact) de sécurité majeur:

Toute personne possédant le mot de passe root sur un compte local peut, d'un simple su - , se changer en un utilisateur dont les données personnelles lui seront alors complètement accessibles grâce au montage NFS

Essayez, le test est très rapide.

Sur les 3 admins avec qui j'en ai parlé, 2 sont tombés des nues et 1 était déjà au courant. Après discussion, voici l'opinion finale de nos vaillants Chevaliers de la Sécurité:

- admin 1: "Bah ouais, mais on peut rien y faire... tant pis, hein..."
- admin 2: "Bah ouais, mais il s'agit de faire confiance a priori aux
utilisateurs ; quelqu'un qui exploiterait ça serait en plein délit ; on peut pas mettre un flic derrière tout le monde, etc."
- admin 3: "Euh, tiens, y'a quand même un problème, là..."

Alors moi, simple utilisateur lambda, bien sûr mon opinion ne compte pas hein, mais je peux pas m'empêcher de trouver pour le moins hypocrite l'attitude consistant à se dire préoccupé des problématiques de sécurité, mais ne rien faire face à un trou aussi béant.

Pour être sûr qu'on se soit bien compris: prenez un réseau interne comme décrit ci-dessus, je dirais comme c'est le cas pour une bonne partie des labos de recherche français. Dans cette configuration, le premier gogo venu, simplement
- en redémarrant une machine Linux en mode single
- ou en installant une distrib linux à partir du cd acheté le matin même dans un magazine
- ou encore en branchant son portable à la place d'une machine existante

peut accéder à un compte root local sur une machine où les comptes des autres utilisateurs peuvent y être montés par NFS. De là notre gogo peut faire ce qu'il veut avec des données personnelles de tous les autres utilisateurs.

Voilà le coup de gueule. D'une part, pour que les personnes dans la même situation que moi se fassent pas d'illusions sur la protection de leurs données. D'autre part pour avoir le retour des personnes qui connaissent déjà le problème, et surtout pour savoir ce qu'ils ont mis eu oeuvre le cas échéant.

eu'l Bob

# Re: Administrateurs, Sécurité et NFS

Posté par Matthieu le 23 avril 2004 à 10:08. Évalué à 2.

à mon avis, c'est juste un problème de configuration de l'export du repertoire NFS.

Qd tu monte le répertoire par NFS tu a l'option root_squash ou no_root_squash. Tu dois avoir la même pour l'export. A vérifier.
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par Matthieu le 23 avril 2004 à 10:12. Évalué à 2.
  
  en lisant le man exports (en français) :
  
  Il est souvent très gênant que le Super-User dune machine cliente soit
  traité comme le Super-User lorsquil accède aux fichiers du serveur.
  Pour éviter ceci, lUID 0 (root) est normalement transformé en un autre
  UID : par exemple en UID anonyme nobody. Ce mode opératoire sappelle
  root squashing et est le comportement par défaut. On peut le sup-
  primer avec loption no_root_squash.
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par bobert le 23 avril 2004 à 10:17. Évalué à 1.
    
    cf mon commentaire ci-dessous (http://linuxfr.org/comments/397286.html(...)).
    
    Le no_root_squash empêche simplement la propagation du root d'une machine à l'autre. Le problème dont je parle est tout autre.
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par monsieurw le 23 avril 2004 à 10:19. Évalué à 2.
    
    Oui, bien sûr, une fois root sur sa machine, on n'a pas accès aux partages NFS grâce à "no_root_squash", mais le problème est qu'on peut créer un utilisateur avec n'importe quel UID, et il est facile de connaître les UIDs des autres utilisateurs. On crée donc un utilisateur ayant l'UID d'un gars, puis un simple "su - legars" permet d'obtenir son identité et d'accéder à ses données partagées par NFS.
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par bobert le 23 avril 2004 à 10:15. Évalué à 2.
  
  Ben oui mais non... ça a aussi été la première réaction d'un des 2 admins qui connaissaient pas le problème !
  
  Cette option de montage évite juste qu'un root local puisse se changer en root sur les autres machines, c'est tout.
  
  Pour les autres comptes, c'est imparable: une fois le montage effectué, les comptes te toto1 et toto2 apparaissent comme de simples répertoires /home/toto1 et /home/toto2 sur la machine ; le root de cette machine peut faire son su - sans problème.
  
  Si tu as un doute, fais le test. Encore une fois y'a rien à faire contre ça, sauf à changer de politique de partage.
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par apkwa le 23 avril 2004 à 10:29. Évalué à 1.
    
    Waw... eh bien... je tombe des nues également... un truc énorme comme NFS...
    
    Mais question (certainement très bête, désolé): est-ce un problème NFS ou NIS ?
    - [^] # Re: Administrateurs, Sécurité et NFS
      
      Posté par bobert le 23 avril 2004 à 10:35. Évalué à 2.
      
      C'est un problème NFS. Effectivement si j'ai bien compris NIS pourrait aider un peu mais ne résourdrait pas tout le problème. Mais là je vais au-delà des retours d'expériences que j'attendais, je préfèrerais que des gens disent ce qu'il en est de leur point de vue à eux.
      - [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par galatea842 le 23 avril 2004 à 15:00. Évalué à 0.
        
        Attention! NIS comme ça n'arrange rien!
        Le réseau de mon université utilise NFS et NIS: résultat lorsque j'installe des machines sous linux pour les assos (ou mon portable), j'ai accès à TOUS les comptes et fichiers de TOUS les étudiants non pas à cause de NFS seul mais SURTOUT à cause de NIS!!!
        En effet: je me connecte en root et la config NFS n'étant pas trop mal faite il m'est impossible de lire les données utilisateurs (option no_root_squash je crois), mais en suite à cause de NIS je peut faire un su login et c'est la catastrophe au niveau sécurité: j'ai accès à tous les fichiers de login en tant que login!!!!
        ça fait depuis que je suis dans cette université que j'en parle aux admins mais rien ne change...
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par Matthieu le 23 avril 2004 à 10:33. Évalué à 10.
    
    Déja, arrête le gras, c'est chiant.
    Deuxièment, arrête de dire que c'est une faille de sécurité majeure, ça n'en est pas une !
    
    Lis le document http://www.freenix.fr/unix/linux/HOWTO/NFS-HOWTO-6.html(...)
    
    Du côté serveur on peut ne pas faire confiance au root du client, avec l'option root_squash (rembarrage du root :-) dans le fichier exports :
    [...]
    Dans ce cas, si un utilisateur du client avec l'UID 0 essaye d'accéder (en lecture, écriture ou effacement) au système de fichiers, le serveur remplace l'UID par celui de l'utilisateur `nobody' du serveur. Ceci signifie que l'utilisateur root du client ne peut accéder/modifier les fichiers du serveur que seul le root du serveur peut accéder/modifier. C'est bien, et vous aurez probablement à utiliser cette option sur tous les systèmes de fichiers que vous exportez. J'en entends un qui me dit : ``Mais l'utilisateur root du client peut toujours utiliser 'su' pour devenir n'importe qui et accéder à ses fichiers !'' Et là je réponds : ``Oui, c'est comme ça, c'est Unix''. Ceci a une conséquence importante : tous les fichiers et binaires importants devraient appartenir à root, et pas bin ou un compte autre que root, car le seul compte auquel le root du client ne peut pas accéder est le compte root du serveur. Plusieurs autres options permettant de ne pas faire confiance à qui ne vous plait pas sont énumérées dans la page de manuel nfsd. Il y a aussi des options pour rembarrer (to squash) des intervalles d'UID ou GID.
    
    Le seul moyen d'exporter les répertoires personnels par NFS, c'est d'exporter les répertoires aux seuls PC de confiance (ceux dont l'utilisateur n'est pas root). Tu peux filtrer l'export par adresse IP, et si cela ne te suffit pas, avec iptables, tu filtres les IP selon les adresses MAC, comme ça tu es sur d'exporter le répertoire à la machine qui à la bonne carte réseau.
    Après tu vas me dire que tu peux booter sur un autre système. Dans ce cas, tu bloques le bios et lilo. Y'a des fonctions de mot de passe, c'est fait pour ça.
    
    Si ça ne te suffit pas, tu regardes du coté des systèmes de fichiers chiffrés, ça peut être une solution.
    - [^] # Re: Administrateurs, Sécurité et NFS
      
      Posté par apkwa le 23 avril 2004 à 10:38. Évalué à 1.
      
      Effectivement... [+1]
      - [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par jojo2002 le 23 avril 2004 à 11:04. Évalué à 3.
        
        Le filtrage IP c'est nul car l'objectif de NFS c'est normalement de faire une discrimination en fonction des users et non des IP (la correspondance IP<-> user n'est jamais bijective).
        
        Ca n'empechera pas de créer sur une machine autorisée un uid permettant d'accéder aux partages d'un petit copain.
        
        La morale : NFS c'est de la merde pour la sécurité. (en plus çà demande les RPC toutes pourries). Les alternatives : Samba ou les nouvelles moutures de NFS qui ont un contrôle d'accès mieux fait.
        
        [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par Colin Leroy (site web personnel) le 23 avril 2004 à 11:40. Évalué à 3.
        
        La morale: NFS c'est fait pour être autorisé aux machines qu'on contrôle et maîtrise. (genre, partage de /var/www ou /usr/src sur des serveurs).
        Pour partager des documents entre utilisateurs en lesquels on n'a pas confiance, on utilise samba ou ssh.
        
        [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par vincent LECOQ (site web personnel) le 23 avril 2004 à 11:52. Évalué à 2.
        
        Ca n'empechera pas de créer sur une machine autorisée un uid permettant d'accéder aux partages d'un petit copain.
        
        avec le compte root je présume ? ...
        si le root décide de créer un utilisateur et donc un nouvel UID, c'est son droit.
        maintenant le filtrage IP indique les machines de confiance depuis les quelles les requêtes NFS sont autorisées, qq soit l'utilisateur (pas bijectives sur l'infini, mais fonctionnel sur un ensemble défini) . Ensuite le système se charge de savoir si l'utilisateur est le bon.
        
        Comme dit plus haut, il suffit de bloquer le bios, cadenacer physiquement les machines, brider lilo et filtrer les UID du root pour être tranquille. maintenant si un utilisateur fait n'importe quoi sur le nain ternet et se retrouve avec un root kit, il ne met en danger que LA machine ou il se trouve, pas le serveur car NFS filtre le root par le squashing ! il ne peut donc se propager (même si la partition NFS est montée, elle est toujour sur le serveur via ton réseau hein ...)
        
        C'est en tout cas le système que j'utilise dans le réseau que j'administre. j'ai choisi NFS parce que Samba ça rame grave !
# Re: Administrateurs, Sécurité et NFS

Posté par kolter (site web personnel, Mastodon) le 23 avril 2004 à 10:14. Évalué à 3.

Je ne voudrais pas dénigrer mais les réponses de tes admins me laisse penser que qu'ils sont incompétents....

M.
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par bobert le 23 avril 2004 à 10:18. Évalué à 2.
  
  J'attends tes conseils avec la plus grande impatience : que proposes-tu à la place ?
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par kolter (site web personnel, Mastodon) le 23 avril 2004 à 10:36. Évalué à 0.
    
    Les docs sur NFS sont claires non ? NFS n'est pas sûr dans les conditions que tu décris alors, on l'utilise pas quand c'est pas sûr.
    
    On autorise que les machines sûres à utiliser NFS et puis c'est tout...
    
    si tu partager des fichiers utilise samba par exemple...
    
    M.
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par Marc Quinton le 23 avril 2004 à 10:41. Évalué à 1.
    
    propose leur une formation unix ;-) tout bon unixien sait que etre root c'est une carte pour le nirvana ...
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par monsieurw le 23 avril 2004 à 10:36. Évalué à 1.
  
  Certes, c'est étonnant que des administrateurs Unix n'aient pas connaissance de ce problème, mais je n'ai pas trouvé de solution pratique pour ce problème de NFS.
  Surtout, il faudrait rigoureusement interdire le branchement de machines non
  autorisées sur le réseau et n'autoriser l'accès root qu'aux administrateurs (et là, les utilisateurs vont râler parce qu'ils ne peuvent plus faire ce qu'ils veulent avec "leur" machine).
  Une autre idée, c'est de n'avoir qu'un fichier chiffré dans son répertoire $HOME qui est monté en loop par l'utilisateur après son login. La clef de chiffrement doit être sur une disquette/carte magnétique/clef USB. Mais ce n'est pas très pratique et ça peut poser des problèmes de performance.
  On peut aussi envisager de ne plus utiliser NFS, mais Samba, par exemple. Il me semble que ce problème peut aussi être résolu avec NFSv4 ( http://www.nfsv4.org(...) et http://www.ietf.org/rfc/rfc3530.txt(...) ), mais c'est encore un peu expérimental.
# Re: Administrateurs, Sécurité et NFS

Posté par kesako le 23 avril 2004 à 10:16. Évalué à 3.

si la machine cliente peut servir a plusieurs personne et donc est configuree pour plusieurs comptes , il me semble qu'on ne peut pas empeche le root de cette machine de faire su - <un login> et d'acceder au compte

C'est un pb d'organisation : si la machine sert a plusieurs personnes, seul l'administrateur devrait connaitre le passwd root.
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par bobert le 23 avril 2004 à 10:32. Évalué à 2.
  
  seul l'administrateur devrait connaitre le passwd root
  
  Certes... mais c'est se défiler face à la réalité. La réalité c'est qu'il est tellement facile (encore une fois):
  - de redémarrer la machine en mode single
  - ou d'installer une distrib linux à partir d'un cd
  - ou encore de brancher son portable à la place de ladite machine
  
  qu'un admin qui aurait un minimum d'honnêteté devrait partir du principe que le compte root de toute machine du réseau est potentiellement exploitable, dans la configuration que j'ai décrite.
  
  Essaie encore !!
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par Matthieu le 23 avril 2004 à 10:36. Évalué à 3.
    
    non, voir message plus haut (http://linuxfr.org/comments/397307.html(...)), faut bloquer l'accès au bios et à lilo par mot de passe.
    
    En gros, la sécurité c'est un tout. Ca ne sert à rien de sécurisé un service sans sécuriser le reste. Un mur près d'un trou ne sert à rien ;-)
    - [^] # Re: Administrateurs, Sécurité et NFS
      
      Posté par Marc Quinton le 23 avril 2004 à 10:45. Évalué à 2.
      
      reste encore le probleme du portable pirate rattaché au réseau. Sans compter que ces précautions (bios et boot) sont rarement prise dans un réseau bureautique et qu'un PC sous windows peut souvent redemarrer sous Linux. Mais il reste encore la barriere des passerelles vers les branches unix a passer en effet souvent les réseaux sont scindés.
      - [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par Matthieu le 23 avril 2004 à 10:48. Évalué à 2.
        
        Le problème du portable pirate attaché au réseau se résoud en filtrant selon les adresses MAC.
        
        Si les précautions ne sont pas prises pour la protection des bios et boot, alors on ne peut rien faire.
        
        Après ça devient du cas par cas.
        
        [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par jojo2002 le 23 avril 2004 à 11:06. Évalué à 4.
        
        Une adresse MAC çà s'usurpe. Tous les contrôles d'accès basés sur du filtrage MAC, IP n'atteindroint jamais l'authentification forte des utilisateurs.
        
        [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par Calim' Héros (site web personnel) le 23 avril 2004 à 11:16. Évalué à 1.
        
        Oui mais dans ce cas une autentification forte des utilisateur, alors que ces dernier on le password root, c'est du reve:)
        
        [^] # Re: Administrateurs, Sécurité et NFS
        
        Posté par jojo2002 le 23 avril 2004 à 11:21. Évalué à 1.
        
        root permet seulement d'être maitre de sa machine mais heureusement pas du réseau (à part la connerie d'un root NIS) donc dans le cas de NFS c'est génant car l'authentif se base sur les uid sur lequel root peut influer.
        
        Pour un autre protocole, root peut usurper l'identité d'un utilisateur mais s'il ne connait pas le secret (mot de passe par exemple ou clé privée) de ce dernier, il ne pourra usurper son authentification plus loin que le système local.
  - [^] # Re: Administrateurs, Sécurité et NFS
    
    Posté par kesako le 23 avril 2004 à 10:41. Évalué à 1.
    
    je n'essaie pas. comme le dit Pascal Terjan plus bas , on ne peut pas empecher cela . Donc pas de montage nfs pour toute machine non absolument sûre . Uniquement du ssh , cvs, samba, ...
# Re: Administrateurs, Sécurité et NFS

Posté par doublehp (site web personnel) le 23 avril 2004 à 10:22. Évalué à 3.

bof ... je m etais plains a l admin de mon ecole que on pouvait rebooter les Linux en mode single ... 3 mois il n as trouve d autre remede que de virer les Linux ... now il n y a plus que des win et des sun. Evidement les Sun posent exactement le pb de NFS que tu viens de decrire, quand aux win, on a trouve 2 autres failles :
- win rapatrie en locale le compte utilisateur lorsqu un user se logue, mais l effacement qui doit intervenire apres que l utilisateur se soit delogue , n est en pratique effectue qu une fois sur deux ... donc si on reboot le PC, et que grace aux 3COM magiques avec menu de boot on switch de DHCP a bootp, on peut forcer le loadage d un OS de son choix ( par ex en metant face a l ex win un portable avec les services qui vont bien: DHCP, BOOTP, FTP ... ), ben on peut se retrouver en position de pouvoir lire tout le disque de la machine. On peut donc recuperer les mails de tous les users dont les comptes locaux n ont pas ete effaces, les mots de passes mails des memes users , mot de passe qui se trouve etre le mdp LDAP, et mot de passe UNIX ( donc des SUN ), et en lisant la cle qui va bien ( je sais plus ou elle est ) dans c:\win, on peut retrouver le mot de passe de l admin du win en moins de 2j de moulinette. Globalement, on a recupere les mails de 30 personnes, leurs mots de passes unix, ce qui donne acces a leur compte unix, et donc a leurs mails, et le mot de passe admin du win. Si on crack le mot de passe admin d un second PC ( le voisin ), on peut facilement retrouver la logique qui regit les mots de passes des PC de la salle, ce qui donne acces sans mal a tous les comptes locaux non effaces.
- en se donnant moins de mal, il existe de petits cracks meme pour 2K et XP pour relire l image du bios du PC ... une moulinette donne en moins de 1s un mot de passe valide pour ce bios, on reboot sur une d7, et on recupere de meme ce que l on veut sur le dur du PC.
. Il existant sur ces memes pc une 3e astuce qui consistait a devisser le capot superieur de la tour, ce qui donne acces a la RAM ( pour l echanger contre une plus petite), et au dur, pour recuperer les infos ci dessus mentionnees).

bref ... voila 3 exemples qui permettent de recouvrer sans trop d efforts 30 comptes utilisateurs, leurs mails, leurs mots de passe UNIX/Mail, et les mdp des win.

d autres eleves avaient fait tourner des moulinettes basees sur des dicos pour recouvrer les mots de passes unix par marteau ... et avaient trouves 30% des mots de passes des profs ( passwd=login, nom de la femme, date de naissance, passwd=nigol [ login a l envers] )

sinon , on a aussi tente un marteau ( john) sur le fichier shadow d un de nos servers, et on a trouve 20% en 2h, 60% en 24h. Au bout de 3j ils n avaient tj pas trouve le mien :=)

Face a toutes ces peripeties, le nouvel admin win a fixe une nouvelle regle: un mot de passe win est valide 3 semaines, doit faire plus de 6l, avec maj, min, chiffre, ET ponctuation ( plus un dico et un historique )
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par kesako le 23 avril 2004 à 10:32. Évalué à 1.
  
  ce qui confirme une regle pas assez souvent respectee : les mots de passe mail ne doivent pas etre les mots de passe unix ou win. Mais pour faciliter la vie a tt le monde on met trop souvent les memes , et on les stocke au meme endroit (ldap, activeDirectory, ...)
# Re: Administrateurs, Sécurité et NFS

Posté par Pascal Terjan (site web personnel) le 23 avril 2004 à 10:27. Évalué à 3.

Oui c'est pour ca que dans le labo ou j'était les machines ou tu est root (mon portable par exemple) n'étaient pas autorisées à monter du NFS et devaient se contenter de samba...
# Re: Administrateurs, Sécurité et NFS

Posté par Sébastien Lardière (site web personnel) le 23 avril 2004 à 10:35. Évalué à 3.

Je n'ai pas de solution toute faite pour ton serveur NFS, mais j'avais déjà remarqué çà.

Mais :

1) Qu'est que vous foutez avec le mot de passe root ? sudo c'est pas fait pour rien !
2) On peut tout à fait empecher de booter sur cdrom ou sur d7.
3) On peut tout à fait empecher de booter en mode single.

Voila, si tes admins ne trouve pas de solution sur le serveur NFS, il peuvent au moins mettre en place la commande sudo, correctement configurée, bien sur, pas question d'avoir le droit de faire un sudo su -, ou autre chose du genre.
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par bobert le 23 avril 2004 à 10:38. Évalué à 1.
  
  Bien sûr qu'on y a pensé, mais je pense qu'une démarche honnête devrait avoir comme prémisse qu'il ne faut pas faire confiance aux root locaux.
# Samba: qu'en est-il ?

Posté par bobert le 23 avril 2004 à 10:47. Évalué à 1.

Comme plusieurs personnes m'ont parlé de samba, pourriez-vous m'en dire plus ? En particulier sur les points suivants:

- un tel problème ne se rencontre pas avec un partage Samba ? Pourquoi ?
- y a-t-il des soucis à se faire au niveau ds performances samba vs nfs (j'ai l'impression que non...)
- y aurait-t-il une perte de certaines fonctionnalités en faisant une migration nfs -> samba ?
- est-ce que ça représente un gros boulot pour mes admins chéris, la migration nfs -> samba ?
- une telle migration nécessite-t-elle des distribs récentes ?
- [^] # Re: Samba: qu'en est-il ?
  
  Posté par jojo2002 le 23 avril 2004 à 11:10. Évalué à 1.
  
  - L'authentification samba ne se base pas sur les uid mais par une authentification type login:mdp donc normalement la "faille" de sécu bien connue de NFS n'existe plus en tant que telle.
  
  - samba ne gère pas les droits Unix et les liens symboliques ???
# Re: Administrateurs, Sécurité et NFS

Posté par ham le 23 avril 2004 à 10:48. Évalué à 2.

NFS n'est pas secure c'est tout. Ce truc est bien connu.

Pour bien faire les choses il faudrait virer le NFS (j'ai entendu parler d'un NFS+), et le remplacer par un FS reseau avec authentification :
samba ou NFS rpc secure.
Pour cela il faut aussi faire de l'authentification reseau :
ldap, samba, kerberos,....

FS reseau authentifié : l'utilisateur prouve son identité (avec des clefs) au serveur de fichier.

authentification reseau: pour distribuer les clefs, seulement pour l'utilisateur qui peut se logguer.

Ensuite si tu est root sur une machine oui il y a des user de loggué tu peut leurs voler leurs token d'identification. on peut limiter les consequences :
utiliser le moins possible ses secret sur d'autre machine non secure :)
# Re: Administrateurs, Sécurité et NFS

Posté par Mickaël Sibelle (site web personnel) le 23 avril 2004 à 11:18. Évalué à 1.

Une question : est-ce que le fait d'utiliser un serveur LDAP pour toute authetification peut résoudre le problème ?
- [^] # Re: Administrateurs, Sécurité et NFS
  
  Posté par niclone (site web personnel) le 23 avril 2004 à 13:27. Évalué à 2.
  
  non
# all_squash

Posté par daggett le 23 avril 2004 à 11:31. Évalué à 3.

Une solution possible, si chaque utilisateur a une station dédiée, et que chaque station de travail
ne serve qu'à un seul utilisateur, et de forcer un all_squash (et non pas seulement un root_squash,
pour le probleme du su justement) avec comme uid/gid forcé celui de l'utilisateur.
Il faut donc une ligne d'export pour chaque station/utilisateur, du genre:

/exports/home/ machine_de_toto.domaine(rw,all_squash,anonuid=uid_de_toto,anongid=gid_de_toto)
/exports/home/ machine_de_ptramo.domaine(rw,all_squash,anonuid=uid_de_ptramo,anongid=gid_de_ptramo)

Ainsi, le serveur NFS considere que tous les acces depuis machine_de_ptramo se font avec l'uid de ptramo,
que l'utilisateur distant soit ptramo, root ou toto.

La "sécurisation" est donc faite par l'IP au lieu de l'uid déclarée du client... Bien sûr c'est toujours
contournable en changeant son IP... donc c'est pas encore ça :/ mais c'est une barriere de plus (l'admin peut au moins mettre en place la vérification de cohérence entre IP et adresse ethernet... zut c'est spoofable aussi...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.