Warum benötigt mount root-Rechte?

Warum verlangt Linux, dass ein Benutzer root / using sudo / spezifisch autorisiert ist, um etwas zu mounten? Es scheint, als ob die Entscheidung, ob ein Benutzer etwas bereitstellen darf, auf seinen Zugriffsrechten auf das Quellvolume / die Netzwerkfreigabe und auf den Bereitstellungspunkt basieren sollte. Einige Verwendungszwecke für das Mounten ohne Rootberechtigung sind das Mounten von Dateisystem-Images in eine benutzereigene Richtung und das Mounten einer Netzwerkfreigabe in ein benutzereigenes Verzeichnis. Wenn der Benutzer die Kontrolle über beide Seiten der Mount-Gleichung hat, sollte alles cool sein.

Erläuterung der Zugangsbeschränkung:

Ich bin der Meinung, dass ich in der Lage sein sollte, alles zu mounten, was der Benutzer ansonsten Zugriff auf einen Mount-Punkt hätte, dessen Eigentümer der Benutzer ist.

Beispielsweise gehört / dev / sda1 auf meinem Computer dem Benutzer root und der Gruppe disk mit Berechtigungen brw-rw----. Nicht-Root-Benutzer können sich daher nicht mit / dev / sda1 anlegen, und mount sollte es ihnen eindeutig nicht erlauben, es anzulegen. Wenn der Benutzer jedoch /home/my_user/my_imagefile.img und mount point / home / my_user / my_image / besitzt, warum sollte er dann nicht in der Lage sein, diese Image-Datei an diesem Mount-Punkt einzuhängen mit:

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

Wie Kormac betonte, gibt es ein schwerwiegendes Problem. Daher müssten einige Einschränkungen hinzugefügt werden, um zu verhindern, dass Suid ein Problem darstellt, sowie möglicherweise einige andere Probleme. Möglicherweise besteht eine Möglichkeit darin, dass das Betriebssystem alle Dateien als zu dem Benutzer gehörend behandelt, der das Mounten durchgeführt hat. Beim einfachen Lesen / Schreiben / Ausführen verstehe ich jedoch nicht, warum dies ein Problem wäre.

Anwendungsfall:

Ich habe ein Konto in einem Labor, in dem mein Speicherplatz zu Hause auf 8 GB beschränkt ist. Das ist winzig und sehr sehr nervig. Ich möchte ein nfs-Volume von meinem persönlichen Server laden, um den verfügbaren Speicherplatz wesentlich zu vergrößern. Da Linux solche Dinge jedoch nicht zulässt, muss ich beim Hin- und Herwechseln von Dateien die 8-GB-Grenze einhalten.

Es ist sowohl eine historische als auch eine Sicherheitsbeschränkung.

In der Vergangenheit waren die meisten Laufwerke nicht austauschbar. Daher war es sinnvoll, das Mounten auf Personen zu beschränken, die einen legitimen physischen Zugriff hatten, und sie würden wahrscheinlich Zugriff auf das Root-Konto haben. Mit den fstab-Einträgen können Administratoren die Bereitstellung von Wechseldatenträgern an andere Benutzer delegieren.

Unter Sicherheitsgesichtspunkten gibt es drei Hauptprobleme, die es beliebigen Benutzern ermöglichen, beliebige Blockgeräte oder Dateisystemabbilder an beliebigen Orten bereitzustellen.

• Durch das Mounten an einem nicht im Besitz befindlichen Speicherort werden die Dateien an diesem Speicherort gespiegelt. Beispiel: Hängen Sie ein Dateisystem Ihrer Wahl /etcmit /etc/shadoweinem Root-Kennwort an, das Sie kennen. Dies wird behoben, indem ein Benutzer ein Dateisystem nur in einem Verzeichnis bereitstellen kann, dessen Eigentümer er ist.
• Dateisystemtreiber wurden häufig nicht so gründlich mit fehlerhaften Dateisystemen getestet. Ein fehlerhafter Dateisystemtreiber kann einem Benutzer, der ein fehlerhaftes Dateisystem bereitstellt, das Einfügen von Code in den Kernel ermöglichen.
• Das Mounten eines Dateisystems kann dem Mounter ermöglichen, dass einige Dateien angezeigt werden, für deren Erstellung er sonst keine Berechtigung hätte. Ausführbare Setuid-Dateien und Gerätedateien sind die offensichtlichsten Beispiele, und sie werden durch die nosuidund nodev-Optionen behoben, die durch das Vorhandensein von userin impliziert werden /etc/fstab.
  Soweit erzwungen userwannmountwird nicht von root aufgerufen ist genug. Im Allgemeinen ist es jedoch problematisch, eine Datei zu erstellen, die einem anderen Benutzer gehört: Der Inhalt dieser Datei wird möglicherweise vom mutmaßlichen Eigentümer anstelle des Mounters zugewiesen. Eine zufällige Attribut-erhaltende Kopie von root in ein anderes Dateisystem würde eine Datei erzeugen, die dem deklarierten, aber nicht beteiligten Eigentümer gehört. Einige Programme prüfen, ob eine Aufforderung zur Verwendung einer Datei legitim ist, indem sie prüfen, ob die Datei einem bestimmten Benutzer gehört, und dies wäre nicht mehr sicher (das Programm muss auch prüfen, ob die Verzeichnisse im Zugriffspfad diesem Benutzer gehören; Wenn willkürliches Mounten erlaubt wäre, müssten sie auch überprüfen, ob keines dieser Verzeichnisse ein Mount-Punkt ist, an dem das Mounten weder von root noch vom gewünschten Benutzer erstellt wurde.

Aus praktischen Gründen ist es heutzutage möglich, ein Dateisystem ohne Rootberechtigung über FUSE bereitzustellen . FUSE-Treiber werden als Bereitstellungsbenutzer ausgeführt, sodass keine Gefahr der Eskalation von Berechtigungen durch Ausnutzen eines Fehlers im Kernelcode besteht. Mit FUSE-Dateisystemen können nur Dateien verfügbar gemacht werden, zu deren Erstellung der Benutzer berechtigt ist, wodurch das letzte Problem oben behoben wird.

Wenn ein Benutzer direkten Schreibzugriff auf ein Blockgerät hat und dieses Blockgerät mounten kann, kann er eine entsprechende ausführbare Datei auf das Blockgerät schreiben, mounten, ausführen und so Root-Zugriff auf das System erhalten. Aus diesem Grund ist das Mounten normalerweise auf root beschränkt.

Jetzt kann root normalen Benutzern das Mounten mit bestimmten Einschränkungen ermöglichen. Er muss jedoch sicherstellen, dass das Mounten nicht zulässig ist, wenn der Benutzer Schreibzugriff auf das Blockgerät hat, und dass auch Devnodes, bei denen ein ähnliches Problem vorliegt (das der Benutzer herstellen kann) ein devnode, der ihnen Schreibzugriff auf ein wichtiges Gerät gibt, auf das sie keinen Schreibzugriff haben sollten).

Es erfordert nicht immer Superprivs. Vonman 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.

Kormac und andere haben darauf hingewiesen, dass dies nicht das Dilemma ist, in dem Sie es darstellen. Es scheint mir, dass dies auf die Philosophie hinausläuft , den Benutzern explizit Berechtigungen gegenüber einem System zu gewähren , bei dem alle Benutzer das unveränderliche Recht hätten , ein Dateisystem zu mounten.

Gilles behebt einige der Sicherheitsprobleme, die beim Mounten von Dateisystemen auftreten. Ich werde rückwirkend eine vorläufige und tangentiale Diskussion über mögliche technische Probleme im Zusammenhang damit vermeiden (siehe Kommentare), aber ich halte es für fair, dass nicht vertrauenswürdige Benutzer kein unveränderliches Recht haben, Festplatten zu mounten.

Das Problem in Bezug auf virtuelle und ferne Dateisysteme (oder ferne Dateisysteme über virtuelle Dateisysteme, a la FUSE) ist weniger bedeutsam, aber die Sicherheitsfrage ist damit nicht gelöst (obwohl FUSE dies könnte und sicherlich Ihr Problem lösen würde). Es ist auch wichtig zu berücksichtigen, dass auf die Daten in solchen Dateisystemen fast immer zugegriffen werden kann, ohne dass ein Gerät gemountet werden muss, entweder durch Dateitransfer oder durch Tools, die ohne Mounten aus Images extrahieren Dies ist kein unüberwindliches Problem beim Zugriff auf Daten, die Sie bizarrerweise in einer Image-Datei abgelegt haben oder (verständlicherweise) von einem Remote-System abrufen möchten. In einer Situation, in der dies nicht der Fall ist, kann es sich lohnen, folgende Fragen zu stellen:

1. Was genau versuche ich zu tun?

2. Wo versuche ich es zu tun?

Wenn die Verwaltung des Systems fair ist, erklärt # 2, warum # 1 für Sie unmöglich ist. Wenn die Verwaltung des Systems nicht fair ist, ist das Politik . Die Lösung für das Problem "Mein Sys-Administrator ist nicht fair" besteht darin, das Betriebssystem nicht neu zu gestalten, sodass Sys-Administratoren die Benutzer nicht überall einschränken können.

Das System ermöglicht dem Superuser, Ihre Aktivitäten entweder explizit oder durch Auslassung einzuschränken ("Wir stellen keine SICHERUNG zur Verfügung" usw.). Privilegien sind ein Mechanismus, mit dem dies erreicht wird. Es mag nicht schön sein zu sagen: "Das musst du nicht tun", aber wenn es wahr ist ... que sera ... musst du das nicht tun. Verwenden Sie FTP usw. Wenn dies nicht der Fall ist, sollten Sie die Verantwortlichen belästigen.

Zu Ihrer Information: Die neuesten Kernel unterstützen "Namespace". Normale Benutzer können einen Namespace erstellen und in diesem Namespace root lustige Dinge wie das Einhängen von Dateisystemen ausführen.

Es gibt Ihnen jedoch keine "echten" Superuser-Berechtigungen - Sie können nur das tun, was Sie bereits dürfen (dh Sie können nur Geräte einbinden, die Sie bereits lesen können).

http://lwn.net/Articles/531114/ Siehe Abschnitt 4.

Da die Daten auf dem Dateisystem, das gemountet werden soll, die Sicherheit des Servers gefährden oder sogar zum Absturz bringen können (wenn dies absichtlich so konstruiert wurde).

In GNOME benötigt gvfs kein Root-Verzeichnis zum Mounten des Remote-Dateisystems (ftp oder ssh) und gnome-mount benötigt auch kein Root-Verzeichnis zum Mounten des externen Speichers (USB-Laufwerk, CD / DVD usw.).

Die meisten Systeme möchten wahrscheinlich nicht das gesamte GNOME nur für eine Remote- Bereitstellung haben , dann können Sie lufs , sshfs oder ftpfs verwenden .

gvfs, lufs, sshfs und ftpfs verwenden FUSE, um Nicht-Root-Benutzern das Mounten des virtuellen Dateisystems zu ermöglichen. und im Gegensatz zu Mount- -o userServern benötigt FUSE keinen Sysadmin, um bestimmte Mount- Server anzuordnen. Solange Sie über die Berechtigung zum Mount-Verzeichnis und zu den Ressourcen verfügen, die zum Erstellen des Dateisystems erforderlich sind, können Sie einen FUSE-Mount erstellen.

Warum benötigt mount root-Rechte?

Denn mountist in erster Linie / ursprünglich für das lokale Dateisystem gedacht, bei dem es sich fast immer um eine Hardware handelt.