Forum Linux.général Compte utilisateur avec droits TRES restreints

Posté par .
Tags : aucun
2
24
nov.
2010
Bonjour,

Je viens demander votre avis expert parce que j'ai un petit souci. Je dois donner un accès ssh sur ma machine perso à qqun que je ne connais absolument pas (je sais, c'est balo, mais croyez moi je n'ai pas le choix). Je vais donc lui créer un compte utilisateur qui ne sera dans aucun groupe sauf le sien.

Mais cela ne l'empechera pas d'avoir accès en lecture à une bonne partie de ma machine (/, /etc, /home/*, ...)

Je pourrais changer les permissions de tout ces dossiers, mais ce serait fastidieux. En plus, si je fais un truc du genre chmod o-r sur des fichiers de configuration (appartenant a root, mais utilisés par des applications utilisateur), ca risque de me mettre une sacré pagaille dans mes applis.

L'idéal serait qu'il n'ait le droit de lire QUE son dossier home, et qu'il ne puisse même pas lister le contenu d'un autre dossier.

Existe-t-il un moyen simple de faire ce genre de choses ?

Merci pour votre aide !

P. Berger
  • # chroot

    Posté par . Évalué à 3.

    Un chroot ?


    Est-ce que ton utilisateur a besoin d'exécuter des commandes via ssh ou juste de lire et écrire des fichiers sur son $home ?

    Si c'est juste pour du transfert de fichiers, tu pourrais aussi lui donner juste un accès à sftp par exemple, avec un chroot réalisé directement par ssh (cf sshd_config pour savoir comment faire ça si tu retiens cette solution)


    Si ton utilisateur doit exécuter des programmes et qu'il n'a que quelques besoins spécifiques, tu dois pouvoir le chrooter avec seulement ces quelques programmes à disposition.
    • [^] # Re: chroot

      Posté par . Évalué à 2.

      Un chroot n'est pas fait pour empêcher les utilisateurs d'accéder au reste du système.

      http://it.slashdot.org/article.pl?sid=07/09/27/2256235

      'chroot is not and never has been a security tool'
      • [^] # Re: chroot

        Posté par . Évalué à 6.

        Ah bon ?
        Et pourquoi OpenBSD fait tourner la plupart de ses démons sous chroot par défaut ?
        Je sais qu'il est facile de sortir d'un chroot lorsque le processus est root, mais lorsqu'il tourne en tant qu'user (fork, chroot, setuid...), ça permet déjà d'éviter toute une classe d'exploits (failles dans programmes setuid, symlinks dans /tmp/, etc). C'est certes plus faible qu'une jail FreeBSD, mais c'est déjà un début. Après, si ton noyau est troué, c'est un autre problème...
        • [^] # Re: chroot

          Posté par (page perso) . Évalué à 1.

          Effectivement, chroot n'est pas un outil de sécurité sur un système linux (qui n'est pas un système à ranger dans la catégorie 'sécurisé'). Par contre, avec un kernel patché grsecurity et contenant les bonnes configurations des 'Chroot restrictions', on doit pouvoir atteindre un niveau de sécurité acceptable.
          • [^] # Re: chroot

            Posté par . Évalué à 3.

            Bonjour,

            Loin de tout troll, peux tu expliquer un peu cette phrase :
            un système linux (qui n'est pas un système à ranger dans la catégorie 'sécurisé')
            En quelques mots, ce que tu en penses, et comment tu définis cette "catégorie sécurisée" (par exemple avec un pointeur vers des normes)

            Merci.

            ps : le patch grsec, tu trouves pas qu'il fait un peu "démo", au final ?
            (que toute la partie "configuration système" devrait être sortie d'un patch "noyau" ?)

            ps2 : ce sont des vraies questions, avec un peu de malice certes. Des pointeurs web de ta part suffiraient à combler ma curiosité. :-)
            • [^] # Re: chroot

              Posté par . Évalué à 5.

              Je vais essayer de répondre, même si la question ne m'est pas adressée...

              En quelques mots, ce que tu en penses, et comment tu définis cette "catégorie sécurisée" (par exemple avec un pointeur vers des normes)

              Par exemple :
              http://en.wikipedia.org/wiki/Evaluation_Assurance_Level

              Après, il faut le prendre avec des pincettes, cela ne veut absolument pas dire qu'un système est sécurisé, c'est juste une certification qui dépend de certains critères...
              Tu noteras que tous les GPOS sont au niveau EAL4.
              Quant à la remarque sur Linux, tu peux la prendre dans le sens où la sécurité n'a jamais été un des buts premiers du noyau, qui est plutôt axé sur les performances. Par exemple, il n'y a pas par défaut de protection du type W^X, pas de protection des stacks, l'entropie pour l'ASLR est assez faible, pas d'access crontrol, etc. Il n'y a pas de mesure de sécurité pro-active, ce qu'essaie de corriger grsec.
              Personnellement, je trouve dommage que les développeurs principaux ne s'intéressent pas plus à la sécurité, on a quasiment toutes les semaines des failles, et pas mal de failles qui permettent à un utilisateur de passer root...

              ps : le patch grsec, tu trouves pas qu'il fait un peu "démo", au final ?
              (que toute la partie "configuration système" devrait être sortie d'un patch "noyau" ?)


              Comprends pas la question. Tu parles du RBAC ?
      • [^] # Re: chroot

        Posté par . Évalué à 2.

        J'avais déjà entendu parler de ça, par contre je n'ai pas trouvé à quoi pouvait bien servir chroot si ce n'est pas dans une optique de sécurité, ne serait-ce que pour éviter qu'un processus buggé n'efface des fichiers par mégarde. Le lien mentionné ci-dessus ne le précise pas : il dit ce que chroot n'est pas, mais pas ce à quoi il est censé servir.


        Bien sûr je suis complètement d'accord pour dire que chroot n'est pas la solution ultime à tous les problèmes et qu'il existera toujours des moyens pour "sortir" du chroot.

        En fonction du problème, ça peut être la solution la plus simple pour générer un environnement "allégé" avec moins de risques de fausses manipulations.
        • [^] # Re: chroot

          Posté par . Évalué à 5.

          chroot sert à... changer la racine. c'est tout :)

          ça (me) sert à bidouiller, installer, réparer, et même créer des systèmes Linux, sur le même disque ou depuis un autre

          par exemple, après un chroot, une commande rpm ou apt-get ira mettre à jour le système chrooté, pas celui d'où tu as lancé la commande chroot
          • [^] # Re: chroot

            Posté par . Évalué à 1.

            C'est vrai qu'à chaque fois que j'utilise chroot directement, c'est pour changer de distrib, ou quand je me retrouve avec un système qui ne boote pas.

            Au moment d'écrire le message, j'aurais dû penser à cette utilisation :)
  • # chroot

    Posté par (page perso) . Évalué à 2.

    Tu le chroot, il aura une jolie arborescence pour lui tous seul et si tu luis dis pas il le remarquera même pas, (tu crée dans le répertoire home du chroot un répertoire au nom de ton login avec accès interdit pour lui).

    Voici un lien qui peut t'aider:
    http://www.majorxtrem.be/2009/04/24/chrooter-un-user-dans-un(...)
    • [^] # Re: chroot

      Posté par . Évalué à 1.

      Merci pour vos réponses.

      C'est vrai que je n'étais pas très précis sur les besoins de mon utilisateur :
      - il doit pouvoir : lire et écrire dans son home
      - compiler et executer des programmes java dans son home, killer la JVM si elle plante (ça arrive si rarement, ... :-) )

      Je maitrise pas du tout le chroot, je vais me renseigner.
      Merci encore pour le coup de main.
      • [^] # Re: chroot

        Posté par . Évalué à 4.

        Vu le besoin, je pense qu'une machine virtuelle minimaliste serait peut-être plus simple à réaliser.

        En effet, je ne suis pas sûr qu'il soit facile d'isoler le processus Java et ses dépendances. Et une fois ces dépendances mises à disposition dans le chroot, je ne suis pas sûr que la sécurité soit bien meilleure que sans le chroot, si tu intègres les 3/4 de ton système ;)
        • [^] # Re: chroot

          Posté par (page perso) . Évalué à 1.

          ou alors avec un container openvz, bon il faut un noyeau spécial, au taf on utilise des serveurs avec proxmox (on a un service = un container).
      • [^] # Re: chroot

        Posté par . Évalué à 2.

        Regardez de ce coté: [http://wiki.archlinux.fr/howto/chroot]
  • # autre possibilité: la machine virtuelle

    Posté par . Évalué à 9.

    Bonjour,

    Si tu pouvais lui interdire tous les répertoires sauf ~, il aurait des problèmes à exécuter les commandes de base n'ayant pas accès /bin. De même avec /etc, certains logiciels ne fonctionneraient pas ou utiliseraient la configuration par défaut. Donc il doit garder l'accès en lecture aux répertoires du système. Normalement, les modifications sont réservées à root, propriétaire de ces fichiers donc il ne peux rien y changer (et ne peux même pas lire /etc/shadow qui contient les mots de passe).

    Tu peux lui barrer l'accès à ton répertoire ~ en lui en interdisant l'accès et la traversée de ce répertoire, il ne pourra alors pas descendre dans l'arborescence. Évidement, tu ne dois pas lui donner l'accès root/sudo.

    Autre solution que le chroot: créer une machine virtuelle sur ta machine avec un ssh que tu rend accessible depuis l'extérieur. Il pourra y faire ce qu'il souhaite (accès root) mais n'aura pas accès aux systèmes de fichier et à la mémoire réels. (mais le chroot ou le sftp suffit peut être à tes besoins).
    • [^] # Re: autre possibilité: la machine virtuelle

      Posté par . Évalué à 2.

      +1 pour la machine virtuelle.

      Si tu veux lui donner accès à certains documents seulement, alors tu pourras :
      - créer un dossier où tu mettras des liens vers les documents
      - restreindre les droits d'accès à ces fichiers/dossiers
      - partager ce dossier avec la machine virtuelle en NFS (Virtualbox le fait très bien, très peu de config sous Linux)
      - utiliser le bon paramétrage réseau pour la VM (ex. Bridged Networking dans Virtualbox) et éventuellement limiter la bande passante sur le périphérique réseau virtuel (avec wondershaper par exemple).

      Comme ça, l'utilisateur sera dans Matrix tout en se croyant dans le monde réel.
  • # une piste

    Posté par . Évalué à 1.

    • [^] # Re: une piste

      Posté par . Évalué à 1.

      une autre piste : choisir d'executer une "session invité" sur ma distribution reduit un certain nombre de droits. Je ne sais pas comment c'est fait, mais je n'arrive pas a aller dans un nombre assez important de répertoires.
      • [^] # Re: une piste

        Posté par (page perso) . Évalué à 2.

        Il me semble que sur Mdv (et d'autres sûrement) le shell de démarrage c'est rbash.
        Ça se configure assez finement apparemment.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # Shells restreints

    Posté par . Évalué à 2.

    Il existe quelques shells "restreints" qui permettent d'empêcher l'utilisateur d'éxecuter certaines commandes et de l'enfermer dans certains répertoires.

    J'utilise pour ma part lshell ( http://lshell.ghantoos.org/ ) qui est extrêmement simple. Attention, cependant, même si tu utilises lshell, l'utilisateur à toujours accès à toute l'arborescence via SFTP. Tu peux l'utiliser conjointement avec MySecureShell (qui comme son nom ne l'explique pas du tout permet d'appliquer des restrictions au serveur SFTP) : voir http://sourceforge.net/projects/lshell/forums/forum/778301/t(...) . Pense également à ulimit pour éviter les attaques de type DoS. Dernière chose, ces deux derniers projets n'ont pas l'air d'avoir été vraiment testés/éprouvés, il a donc surement des failles de sécurité dedans.

    Il existe également GNU Rush, qui a l'air plus puissant (peut-être plus securisé) : http://puszcza.gnu.org.ua/software/rush/manual/html_section/(...)

    Sinon, comme dit plus haut il y a l'option chroot de SSH ou les jails de type OpenVZ/Vserver/LXC qui présentent à mon avis l'inconvénient d'être plus lourds à mettre en place (et surement overkill...).
  • # Chrooter le SFTP

    Posté par . Évalué à 1.

    Si le but est de permettre du SFTP (scp), il y a une astuce très simple, dans le fichier de configuration du sshd:

    Subsystem sftp internal-sftp

    Match Group untrusted
        ChrootDirectory %h
        ForceCommand internal-sftp


    Ainsi, les utilisateurs du groupe untrusted sont chrootés dans le dossier personnel (%h), et ne peuvent que faire du sftp.

Suivre le flux des commentaires

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