Pourquoi mount requiert-il des privilèges root?


54

Pourquoi Linux exige-t-il qu'un utilisateur soit root / en utilisant sudo / spécifiquement autorisé par montage pour pouvoir monter quelque chose? Il semble que la décision d'autoriser un utilisateur à monter quelque chose doit être basée sur ses droits d'accès au volume source / partage réseau et au point de montage. Deux utilisations possibles du montage non root sont le montage d'images de système de fichiers dans une direction appartenant à l'utilisateur et le montage d'un partage réseau dans un répertoire appartenant à l'utilisateur. Il semble que si l'utilisateur a le contrôle des deux côtés de l'équation de montage, tout devrait être cool.

Clarification de la restriction d'accès:

J’estime que je devrais pouvoir monter tout ce que l’utilisateur aurait autrement accès à un point de montage dont il est le propriétaire.

Par exemple, sur mon ordinateur, / dev / sda1 appartient à l'utilisateur root et au disque de groupe avec autorisations brw-rw----. Par conséquent, les utilisateurs non root ne peuvent pas jouer avec / dev / sda1 et clairement, mount ne devrait pas leur permettre de le monter. Toutefois, si l'utilisateur possède /home/my_user/my_imagefile.img et le point de montage / home / mon_utilisateur / mon_image / pourquoi ne devrait-il pas pouvoir monter ce fichier image sur ce point de montage avec:

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

Comme l'a souligné Kormac, il existe un problème suid. Il faudrait donc ajouter certaines restrictions pour éviter que le suid ne soit un problème, ainsi que potentiellement d’autres problèmes. Une façon de procéder serait peut-être de faire en sorte que le système d'exploitation traite tous les fichiers comme appartenant à l'utilisateur qui a effectué le montage. Cependant, pour une lecture / écriture / exécution simple, je ne vois pas pourquoi cela poserait un problème.

Cas d'utilisation:

J'ai un compte dans un laboratoire où l'espace de mon domicile est limité à 8 Go. C'est minuscule et très très énervant. Je souhaite monter un volume nfs à partir de mon serveur personnel pour augmenter sensiblement le volume d'espace disponible. Cependant, comme Linux ne permet pas à de telles choses, je suis coincé avec les fichiers scp'ing dans les deux sens pour rester sous la limite de 8 Go.


4
Il semble que le problème ne soit pas tant que "Linux ne permet pas de telles choses", car vous n'êtes pas autorisé à faire de telles choses dans votre laboratoire, car le système pourrait être configuré pour vous permettre de le faire. Vous pouvez discuter de cette question avec les personnes qui administrent le système. s'ils ne sont pas amis, alors il s'agit de politique et non d'ordinateur;)
goldilocks

Est-il possible de monter des points de montage arbitraires auxquels on a normalement accès? Il semblerait que l'administrateur devrait ajouter une ligne explicite au fstab pour mon montage nfs afin de l'autoriser. À son tour, cela créerait probablement un précédent dans lequel ils devraient également faire de même pour tous les autres qui le demandent, ce qui, je le comprends bien, serait intenable. D'où la question de savoir pourquoi Linux ne vous permet pas de monter des objets arbitraires qui seraient sans danger (de manière restreinte).
CrazyCasta

10
Avez-vous essayé sshfs? Il montera un répertoire distant, via sshvous-même, sans avoir besoin d'un accès root. Il faut juste que FUSE (Filesystem in UserSpacE) soit installé.
Arcege

1
Vous avez entendu parler du problème des disques durs défectueux, etc. Ainsi, je sais que je l'ai déjà dit plusieurs fois, mais la philosophie est qu'il est impossible de "sécuriser les choses de manière arbitraire" , et c'est pourquoi is (des exceptions spécifiques doivent être organisées). BTW, si vous n'avez pas FUSE, sftpest un peu plus agréable à utiliser que scp.
goldilocks

1
Cela ressemble à (une variante de) cela a déjà été demandé ici auparavant: Monter un fichier de boucle sans autorisation root?
Daniel Pryden

Réponses:


37

C'est à la fois une restriction historique et de sécurité.

Historiquement, la plupart des lecteurs n'étaient pas amovibles. Il était donc logique de limiter le montage aux personnes ayant un accès physique légitime et qui auraient probablement accès au compte root. Les entrées fstab permettent aux administrateurs de déléguer le montage aux autres utilisateurs pour les lecteurs amovibles.

Du point de vue de la sécurité, permettre à des utilisateurs arbitraires de monter des périphériques de blocs ou des images de système de fichiers à des emplacements arbitraires pose trois problèmes majeurs.

  • Le montage sur un emplacement n'appartenant pas au propriétaire masque les fichiers à cet emplacement. Par exemple: montez un système de fichiers de votre choix /etcavec un /etc/shadowmot de passe root que vous connaissez. Ceci est corrigé en permettant à un utilisateur de monter un système de fichiers uniquement sur un répertoire qu'il possède.
  • Les pilotes de système de fichiers n'ont souvent pas été testés de manière aussi approfondie avec un système de fichiers mal formé. Un pilote de système de fichiers défectueux pourrait permettre à un utilisateur fournissant un système de fichiers mal formé d’injecter du code dans le noyau.
  • Monter un système de fichiers peut permettre au monteur de faire apparaître certains fichiers qu'il n'aurait autrement pas la permission de créer. Exécutables setuid et fichiers appareil sont les exemples les plus évidents, et ils sont fixés par les nosuidet les nodevoptions qui sont sous - entendus en ayant userdans /etc/fstab.
    Jusqu'ici en vigueur userquandmountn'est pas appelé par root est suffisant. Mais plus généralement, pouvoir créer un fichier appartenant à un autre utilisateur est problématique: le contenu de ce fichier risque d’être attribué au prétendu propriétaire au lieu du monteur. Une copie occasionnelle préservant les attributs par root sur un système de fichiers différent produirait un fichier appartenant au propriétaire déclaré, mais non impliqué. Certains programmes vérifient que la demande d'utilisation d'un fichier est légitime en vérifiant que le fichier appartient à un utilisateur particulier et que cela ne serait plus sans danger (le programme doit également vérifier que les répertoires du chemin d'accès appartiennent à cet utilisateur; si le montage est autorisé de manière arbitraire, ils devront également vérifier qu'aucun de ces répertoires n'est un point de montage où le montage n'a été créé ni par root ni par l'utilisateur souhaité).

Pour des raisons pratiques, il est aujourd'hui possible de monter un système de fichiers sans être root, via FUSE . Les pilotes FUSE s'exécutant en tant qu'utilisateur en montage, il n'y a donc aucun risque d'élévation des privilèges en exploitant un bogue du code du noyau. Les systèmes de fichiers FUSE peuvent uniquement exposer les fichiers que l'utilisateur est autorisé à créer, ce qui résout le dernier problème mentionné ci-dessus.


24

Si un utilisateur a un accès direct en écriture à un périphérique bloc et peut monter ce périphérique bloc, il peut alors écrire un exécutable suid sur le périphérique bloc, le monter et l'exécuter, afin d'obtenir un accès root au système. C'est pourquoi le montage est normalement limité à la racine.

Maintenant, root peut autoriser les utilisateurs normaux à monter avec des restrictions spécifiques, mais il doit s’assurer que si l’utilisateur a un accès en écriture sur le périphérique bloc, le montage interdit le suid, ainsi que devnode, qui ont un problème similaire (l’utilisateur peut devnode qui leur donne un accès en écriture à un périphérique important auquel ils ne devraient pas avoir accès en écriture).


8

Il ne nécessite pas toujours de super privs. Deman mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

Oui, vous avez raison, ma question était un peu imprécise. Je suis conscient que l'on peut être spécifiquement autorisé sur une base de montage. Mais il semble que si le point de montage et le volume appartiennent tous les deux à l'utilisateur, l'utilisateur devrait pouvoir monter sans autorisation spécifique.

3
@CrazyCasta: le point de montage peut appartenir à l'utilisateur, mais pas le nœud du périphérique. Ce que sont les propriétés, etc., sur les données de la partition est a) inconnaissable, b) non pertinent.
goldilocks

Mais que se passe-t-il si le nœud de périphérique appartient à l'utilisateur?
CrazyCasta

Ensuite, il devrait y avoir une exception parallèle dans fstab, puisqu'un nœud de périphérique appartenant à un utilisateur serait exceptionnel pour commencer (essayez d’en créer un). Encore une fois, le principe est qu’un système sécurisé est restreint et que des privilèges sont accordés à des personnes. Si vous ne l’avez pas obtenu, vous n’avez malheureusement pas de chance. Vous voyez, * nix ne vend pas de magazines de grande capacité au comptoir - vous avez besoin d’un permis.
goldilocks

Pour être clair, l' mount()appel système nécessite toujours root. Les utilitaires suid peuvent devenir root et autoriser les utilisateurs non root à monter. Si la mountcommande est installée suid, elle le fera en fonction de l'indicateur utilisateur dans fstab. D'autres exécutables suid ont été écrits pour permettre aux utilisateurs de monter, tels que pmount, ce qui leur permet de monter un support externe et d'appliquer les restrictions appropriées, telles que nosuid, nodev.
Psusi

5

Kormac et d’autres ont indiqué que ce n’était pas le dilemme que vous présentez. il me semble que cela revient à la philosophie qui consiste à accorder explicitement des privilèges utilisateur à un système dans lequel tous les utilisateurs auraient le droit immuable de monter un système de fichiers.

Gilles résout certains des problèmes de sécurité associés au montage de systèmes de fichiers. J'éviterai rétroactivement une discussion prologue et tangentielle sur des problèmes techniques potentiels liés à ce problème (voir commentaires), mais j'estime qu'il est juste que les utilisateurs non fiables ne disposent pas d'un droit immuable de monter des disques durs.

Le problème concernant les systèmes de fichiers virtuels et distants (ou les systèmes de fichiers distants via des systèmes de fichiers virtuels à la FUSE) est moins important, mais cela ne résout pas la question de la sécurité (bien que FUSE puisse le faire, cela résoudrait certainement votre problème). Il est également important de noter que les données de tels systèmes de fichiers sont presque toujours accessibles sans montage de périphérique, que ce soit par transfert de fichiers ou par des outils permettant d'extraire des images sans montage. Par conséquent, un système qui ne vous permet pas de monter pas un problème insurmontable en ce qui concerne l’accès aux données que vous avez bizarrement placées dans un fichier image, ou (plus compréhensible) que vous souhaitez obtenir d’un système distant. Si vous avez une situation où ce n'est pas le cas, cela vaut la peine de demander:

  1. Qu'est-ce que j'essaie de faire exactement?

  2. Où est-ce que j'essaie de le faire?

Si l'administration du système est équitable, alors la n ° 2 explique pourquoi la n ° 1 vous est impossible. Si l'administration du système n'est pas juste, c'est de la politique . La solution au problème, "Mon administrateur système n'est pas juste" ne consiste pas à redéfinir le système d'exploitation, de sorte que les administrateurs système de partout ne puissent pas restreindre les utilisateurs.

Le système permet au super utilisateur de restreindre vos activités, soit explicitement, soit par omission ("Nous ne fournissons pas de FUSE", etc.). Les privilèges sont un mécanisme par lequel cela est accompli. Ce n'est peut-être pas agréable de se faire dire: "Vous n'avez pas besoin de faire ça", mais si c'est vrai ... que sera ... vous n'avez pas besoin de faire ça. Utilisez ftp, etc. Si ce n'est pas vrai, vous devriez harceler les responsables.


Votre réponse est confuse. Les volumes eux-mêmes (par exemple, / dev / sda1, / dev / sda2, etc.) ne sont-ils pas protégés de la lecture / écriture par les utilisateurs? Je me demande pourquoi un utilisateur ne peut pas monter quelque chose auquel il aurait normalement accès. Pour clarifier, si j'ai un fichier image portant l'extension ext2, je pourrais écrire une application qui me permet de lire / écrire de / vers ladite image (pas dans le système de fichiers du système d'exploitation, bien sûr). Cette application ne pourrait pas lire / écrire à partir des partitions de / dev (sauf si ces partitions ont été modifiées pour permettre à l'utilisateur d'y accéder, ce qui n'a généralement aucun sens).
CrazyCasta

PS: Je ne suis pas d’accord pour dire que les utilisateurs devraient pouvoir monter un système de fichiers auquel ils n’auraient autrement pas accès sans autorisation spécifique, car le simple fait de le monter pourrait potentiellement provoquer une sorte d’action (telle que la vérification du système de fichiers) que la racine ne souhaitait pas.
CrazyCasta

Le montage d'une image implique toujours des nœuds de périphérique (par exemple, / dev / loop). Vous avez raison de dire que cela crée un problème, mais "prendre des dispositions" en ce sens varie d'un système à l'autre (l'offre de périphériques à boucle est finie, par exemple), c'est pourquoi, par défaut, tout est restreint. Mais ce défaut peut toujours être remplacé par le super utilisateur, au nom de qui que ce soit.
goldilocks

C'est un bon point concernant la limite des nœuds de périphérique en boucle. Je ne comprends pas vraiment pourquoi il faut un dispositif de bouclage, cela semble un peu redondant. Je sais que c'est parce que le montage nécessite un fichier par blocs plutôt qu'un fichier normal. Je ne comprends pas pourquoi c'est bien. Pouvez-vous donner un aperçu, comme le noyau traite-t-il différemment les périphériques en mode bloc et les fichiers normaux?
CrazyCasta

1
@ goldilocks: La raison pour laquelle cette réponse est absurde est que votre théorie derrière la restriction est très convaincante, mais elle est totalement fausse, le problème que vous avez mentionné n'existe pas. Autoriser la création d'un système de fichiers virtuel (comme FUSE) ne vous permet pas de faire quoi que ce soit qui n'est pas déjà possible de manière plus détournée en utilisant IPC. Votre note concernant les interruptions sur les appareils est totalement hors de propos. la seule interruption significative qui se produit pour le système de fichiers distant provient de la carte réseau, qui est entièrement gérée par le noyau.
Lie Ryan

5

FYI: Les nouveaux noyaux ont un support "namespace". Les utilisateurs ordinaires peuvent créer un espace de noms et, au sein de celui-ci, devenir root et faire des choses amusantes telles que le montage de systèmes de fichiers.

Cela ne vous donne cependant pas de "vraies" autorisations de super-utilisateurs - vous ne pouvez faire que ce que vous êtes déjà autorisé à faire (c.-à-d. Que vous ne pouvez monter que des périphériques que vous pouvez déjà lire).

http://lwn.net/Articles/531114/ Voir section 4.


Les espaces de noms sont plus limités que cela. Vous pouvez apparaître rootdans un espace de noms utilisateur, mais cela ne vous permet pas de monter des types de système de fichiers normaux, même si vous pouvez lire et écrire le périphérique de blocage. Voir l'expérience 2 ici: unix.stackexchange.com/questions/517317/…
sourcejedi

0

Parce que les données sur le système de fichiers qu'ils ont l'intention de monter risquent de compromettre la sécurité du serveur, voire de le faire planter (s'il a été construit intentionnellement de cette façon).


Pourriez-vous élaborer? Je ne suis pas sûr que "les données sur le système de fichiers qu'ils ont l'intention de monter" compromettent la sécurité. Si vous pouvez lire / écrire le fichier normalement, vous devriez pouvoir le monter (c'est mon argument). Si je peux lire / écrire un point de montage, je devrais pouvoir tout monter, à l'exception du fait de le monter dans un répertoire. Si vous ne pouvez pas le lire / l'écrire, ou ne pouvez pas afficher le répertoire dans lequel il se trouve, le montage échouera de la même manière qu'une commande de type ls ou cat.

Votre argument est valide si vous êtes l'utilisateur unique. Rappelez-vous que Linux (et Unix) sont des systèmes multi-utilisateurs, dans lesquels les utilisateurs ne sont pas nécessairement de confiance.
sendmoreinfo

Des fichiers binaires suid peuvent être ajoutés à un périphérique, montés sur votre boîte et utilisés pour enraciner une boîte. C'est pourquoi, par défaut owneret user(s)définis nosuid. Vous ne voudriez pas que quelqu'un puisse contourner cela facilement en leur permettant de retirer manuellement lenosuid
RS

@sendmoreinfo Je suis bien conscient que Linux est un système multi-utilisateur, il n'est pas nécessaire d'être condescendant. Je me demande pourquoi je ne suis pas autorisé à monter des partages réseau et des fichiers image auxquels je suis par ailleurs largement accessible. La réponse de kormoc est éclairante, mais je suis curieux de savoir pourquoi certains indicateurs ne pourraient pas être forcés sur des utilisateurs non-root (comme nosuid) pour résoudre ce problème. Il semble que je devrais être capable de monter à des fins de lecture / écriture simples un fichier image / un partage réseau auquel j'ai normalement accès sur un point de montage que je possède.
CrazyCasta

1
@CrazyCasta WRT "faisant planter le système", il est certainement possible de monter du matériel défectueux qui exploite les vulnérabilités de l'interface matérielle. Quiconque a un disque dur avec suffisamment de blocs défectueux peut vous dire comment il peut affecter le noyau (et donc tout le système) - il entre dans une boucle occupée et paralyse efficacement le kit complet et le kaboodle. Il y a probablement une logique à la base de ce qui rend impossible à résoudre, car il s'agit d'un problème bien connu qui existe depuis longtemps sans solution.
goldilocks

0

Dans GNOME, gvfs n’a pas besoin de root pour monter un système de fichiers distant (ftp ou ssh) et gnome-mount n’a pas non plus besoin de root pour monter un stockage externe (lecteur USB, CD / DVD, etc.).

La plupart des systèmes ne voudront probablement pas disposer de GNOME dans son intégralité uniquement pour un montage distant, vous pouvez alors utiliser lufs , sshfs ou ftpfs .

gvfs, lufs, sshfs et ftpfs utilisent FUSE pour permettre aux utilisateurs non root de monter un système de fichiers virtuel; et contrairement à mount -o user, FUSE n’a pas besoin de l’administrateur système pour organiser des montages spécifiques. Tant que vous avez le privilège de disposer du répertoire de montage et des ressources nécessaires pour construire le système de fichiers, vous pouvez créer un montage FUSE.

Pourquoi mount requiert-il des privilèges root?

Car mountest principalement / initialement destiné au système de fichiers local, qui implique presque toujours un matériel.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.