Système de fichiers en réseau avec sécurité de niveau utilisateur pour Linux

8

Je souhaite activer le partage de fichiers entre les serveurs et les clients, tous deux sous Linux. Je ne veux pas compter sur la confiance des machines comme dans NFSv4 car les utilisateurs clients auront des privilèges root. Quelles sont mes options en plus de SMB (SAMBA)? OpenAFS prend-il en charge l'authentification et l'accès au niveau utilisateur? L'utilisation de WebDAV / ftp / sshfs monté semble idiot pour le LAN.

— Konrads
source

Voulez-vous dire qu'ils ont un accès root aux serveurs ou simplement à leurs propres machines clientes?

— wag2639

14

Je ne suis pas sûr de bien comprendre:

"Je ne veux pas compter sur la confiance des machines comme dans NFSv4 car les utilisateurs clients auront des privilèges root."

Si vous voulez dire que les utilisateurs clients auront des privilèges root sur le client et que vous ne voulez pas qu'ils aient root sur l'hôte, alors vous n'utilisez simplement pas l'option "no_root_squash". Vous pouvez également faire des choses comme désactiver setuid pour aider à réduire le risque pour le client du serveur.

Vous avez également la possibilité d'utiliser des kerberos avec NFSv4, voir ce lien .

En d'autres termes, NFSv4 pourrait vous donner la sécurité dont vous avez besoin tout en étant un peu plus ... (évolutif?) .. en utilisant sshfs partout. Ce n'est peut-être pas encore ce que vous voulez, mais je n'y renoncerais pas trop tôt.

— Kyle Brandt
source

Par exemple, j'ai deux projets / joeisworking et / mattisworking. Même si je fais de la racine de squash, Matt depuis son poste de travail peut accéder à Joe.

— Konrads

2

@ Konrads: Pas si vous utilisez des kerberos, comme l'a mentionné M. Brandt. Même si matt a racine sur son propre poste de travail, il ne peut pas obtenir le TGT de Joe.

— janneb

Je pense que Konrads ne sait tout simplement pas comment configurer NFS, ou a déjà rencontré un réseau mal configuré. NFS peut être très sécurisé et peut accomplir exactement ce qui est décrit dans la question. Je dirais que NFSv4 est l'un (sinon le plus) du système de fichiers réseau sécurisé (lorsqu'il est correctement configuré).

— Chris S

3

Avec Kerberos, seul le serveur kdc accorde des jetons d'authentification. Une machine cliente seule ne peut s'authentifier qu'en tant qu'hôte (et c'est si vous lui donnez le keytab à un nfs / client-hostname @ REALM correspondant), et cela ne lui donne que le droit de parler au serveur nfs. Ce sont les utilisateurs qui ont la possibilité de s'authentifier, et le serveur nfs ne les autorise qu'à accéder à leurs propres fichiers. Avec sec = krb5p, le serveur empêche également l'espionnage et l'altération.

Être root ne donnera pas à vos utilisateurs des privilèges inappropriés. La seule façon pour eux d'accéder à plus de fichiers est de se pirater mutuellement les machines, de pirater le serveur nfs ou le kdc. NFSv4 avec Kerberos répond bien à vos exigences de sécurité.

En savoir plus sur le modèle de sécurité:

Concevoir un système d'authentification: un dialogue en quatre scènes

Si vous envisagez un déploiement, voici quelques tutoriels centrés sur Debian / Ubuntu. J'ai choisi des configurations simples sans LDAP. Ces distributions ont une configuration basée sur debconf qui vous aide à y arriver.

Configuration de Kerberos (notez les exigences fqdn).
Configuration de NFSv4

Mes ajouts: vous n'avez pas besoin de spécifier un enctype des-cbc-crc, mais vous devez autoriser_weak_crypto dans krb5.conf afin que le protocole de communication puisse utiliser des-cbc-crc pour le chiffrement de flux. Cela deviendra inutile dans les noyaux 2.6.35.

Si vous cherchez quelque chose qui ressemble à un appareil, il y a FreeIPA .

— Tobu
source

C'est intéressant, jusqu'à présent j'ai compris qu'il n'y a que l'authentification de serveur à serveur dans NFSv4 et que le système qui monte le volume exporté est responsable du tri des autorisations (squash_root_fs étant l'exception). Pouvez-vous fournir des liens vers des documents?

— Konrads

2

sshfs est la voie à suivre. Sur le client:

sshfs -o idmap=user,workaround=rename user@server:/home/user/share /home/user/share

Autorisations identiques à ssh ... car vous utilisez ssh! Une bonne chose est que vous n'avez rien à toucher sur le serveur, en supposant que sshd est installé et fonctionne correctement. Pourrait ne pas avoir les performances comme les autres suggestions, mais c'est très simple.

— SuperJames
source

0

la samba ressemble vraiment à votre meilleur pari. samba a des extensions unix donc quand il est monté en utilisant comme cifs sur linux il devrait montrer les permissions unix appropriées et ainsi de suite. Je pense que ce sera la meilleure option pour vos contraintes. si cela ne fonctionne pas, sshfs pourrait être utilisé à la rigueur mais il n'aura pas de bonnes performances ou intégration dans le système d'exploitation comme samba.

— mtinberg
source

0

OpenAFS prend-il en charge l'authentification et l'accès au niveau utilisateur?

Oui, il semble qu'OpenAFS satisferait vos exigences ici, mais il en serait de même pour Kerberized NFSv4. Dans ces deux environnements, vous n'avez pas besoin de «faire confiance» aux clients; le contrôle d'accès est appliqué par les serveurs. Les versions précédentes de NFS vous obligeaient à «faire confiance» aux clients, mais Kerberized NFSv4 ne le faisait pas. OpenAFS n'a jamais exigé de clients "de confiance" et s'appuie également sur Kerberos pour l'authentification et la sécurité.

— une raison
source