Ist es möglich, bestimmten Benutzern (z. B. Mitgliedern einer Gruppe) das Mounten eines Dateisystems ohne Superuser-Berechtigungen unter Linux zu ermöglichen?

Eine andere Frage könnte lauten: "Inwiefern kann ein Benutzer einem System Schaden zufügen, wenn er Dateisysteme einbindet?"

Es gibt einige Ansätze, von denen einige größtenteils sicher sind, andere überhaupt nicht.

Der unsichere Weg

Lassen Sie jede Verwendung laufen mount, z. B. durch sudo. Du könntest ihnen genauso gut Wurzel geben; das ist gleich. Der Benutzer könnte ein Dateisystem mit einer suid-Root-Kopie von bash-running mounten, die sofort root gibt (wahrscheinlich ohne Protokollierung, über die Tatsache hinaus, dass sie ausgeführt mountwurde).

Alternativ könnte ein Benutzer sein eigenes Dateisystem darüber mounten /etc, das seine eigene Kopie von /etc/shadowoder enthält /etc/sudoers, und dann root mit entweder suoder beziehen sudo. Oder möglicherweise bind-mount ( mount --bind) über eine dieser beiden Dateien. Oder eine neue Datei in /etc/sudoers.d.

Ähnliche Angriffe könnten über /etc/pam.dund an vielen anderen Orten abgeworfen werden.

Denken Sie daran, dass sich Dateisysteme nicht einmal auf einem Gerät befinden müssen, sondern -o loopeine Datei bereitstellen, die dem Benutzer gehört (und daher geändert werden kann).

Der meist sichere Weg: udisks oder ähnliches

Die verschiedenen Desktop-Umgebungen haben bereits Lösungen dafür entwickelt, damit Benutzer Wechseldatenträger bereitstellen können. Sie funktionieren, indem sie nur in einem Unterverzeichnis von gemountet werden /mediaund die Unterstützung für Benutzer- / Gruppen-IDs über Kerneloptionen deaktivieren. Optionen hier sind udisks, udisks2, pmount, usbmount,

Wenn Sie müssen, können Sie Ihr eigenes Skript schreiben, um etwas Ähnliches zu tun, und es über sudo aufrufen - aber Sie müssen beim Schreiben dieses Skripts sehr vorsichtig sein, um keine Root-Exploits zu hinterlassen. Wenn Sie nicht möchten, dass sich Ihre Benutzer an sudo erinnern müssen, können Sie in einem Skript Folgendes tun:

#!/bin/bash
if [ $UID -ne 0 ]; then       # or `id -u`
    exec sudo -- "$0" "$@"
fi

# rest of script goes here 

Der Weg, der eines Tages sicher sein wird: Benutzernamensräume

Linux-Namespaces sind eine sehr einfache Form der Virtualisierung (genauer gesagt Container). Insbesondere mit Benutzernamensräumen kann jeder Benutzer im System seine eigene Umgebung erstellen, in der er sich als Root befindet. Dies würde es ihnen ermöglichen, Dateisysteme bereitzustellen, mit der Ausnahme, dass dies mit Ausnahme einiger virtueller Dateisysteme explizit blockiert wurde. Möglicherweise werden FUSE-Dateisysteme zugelassen, aber die neuesten Patches, die ich finden konnte, decken keine Blockgeräte ab , sondern nur Dinge wie sshfs.

Darüber hinaus haben viele Distributionskerne (aus Sicherheitsgründen) standardmäßig nicht zugelassen, dass nicht privilegierte Benutzer Benutzernamensräume verwenden. Zum Beispiel hat Debian eine kernel.unprivileged_userns_clone, die standardmäßig auf 0 eingestellt ist. Andere Distributionen haben ähnliche Einstellungen, obwohl sie oft leicht unterschiedliche Namen haben.

Die beste mir bekannte Dokumentation zu Benutzernamensräumen ist ein LWN-Artikel Namespaces in operation, Teil 5: Benutzernamensräume .

Im Moment würde ich mich für udisks2 entscheiden.

Sie können dies tun, müssen jedoch den Eintrag in /etc/fstabdem Dateisystem ändern , das Sie bereitstellen möchten, und userdiesem Eintrag das Flag hinzufügen . Benutzer ohne Privilegien könnten es dann mounten.

Sehen Sie man mountfür weitere Details.

Hier ist das Wiki zum Konfigurieren von Polkit- Regeln für udisks / udisks2 , um Partitionen von Nicht-Root-Gruppen (z. B. Benutzern) bereitzustellen .

Speichern Sie den folgenden Code in /etc/polkit-1/rules.d/50-udisks.rules

polkit.addRule(function(action, subject) {
  var YES = polkit.Result.YES;
  var permission = {
    // only required for udisks1:
    "org.freedesktop.udisks.filesystem-mount": YES,
    "org.freedesktop.udisks.filesystem-mount-system-internal": YES,
    "org.freedesktop.udisks.luks-unlock": YES,
    "org.freedesktop.udisks.drive-eject": YES,
    "org.freedesktop.udisks.drive-detach": YES,
    // only required for udisks2:
    "org.freedesktop.udisks2.filesystem-mount": YES,
    "org.freedesktop.udisks2.filesystem-mount-system": YES,
    "org.freedesktop.udisks2.encrypted-unlock": YES,
    "org.freedesktop.udisks2.eject-media": YES,
    "org.freedesktop.udisks2.power-off-drive": YES,
    // required for udisks2 if using udiskie from another seat (e.g. systemd):
    "org.freedesktop.udisks2.filesystem-mount-other-seat": YES,
    "org.freedesktop.udisks2.encrypted-unlock-other-seat": YES,
    "org.freedesktop.udisks2.eject-media-other-seat": YES,
    "org.freedesktop.udisks2.power-off-drive-other-seat": YES
  };
  if (subject.isInGroup("users")) {
    return permission[action.id];
  }
});

Angenommen, Sie befinden sich in der Gruppe "Benutzer" und mounten eine Partition mit dem folgenden Befehl (sudo ist nicht erforderlich).

# udisks2
udisksctl mount --block-device /dev/sda1

# udisks
udisks --mount /dev/sda1

1 Schau, wo es funktioniert

Unter Xubuntu funktioniert das Einhängen und Auswerfen von USB-Massenspeichern, Festplattenpartitionen, CDs / DVDs und wahrscheinlich mehr.

Nehmen wir an, dass die von Ubuntu mit policyKit gewählte Lösung sicher genug ist.

2 Wählen Sie das relevante Teil aus

Unter XFCE unter Debian 8.3 musste ich dem Benutzer erlauben, Dateisysteme von Thunar ohne Passwort zu mounten und auszuwerfen. Was für mich funktioniert hat, ist, eine Berechtigungsdatei von Ubuntu auszuwählen.

Das Hinzufügen der folgenden Zeilen als root zu einer Datei mit dem Namen /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pklasollte den Trick machen:

[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.udisks.filesystem-*;org.freedesktop.udisks.drive-ata-smart*;org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.encrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
ResultActive=yes

3 Gewinn!

(Eigentlich habe ich unter Ubuntu 16.04 etwas mehr aus der gleichnamigen Datei herausgesucht und es hat bei mir funktioniert. Wenn Sie es brauchen, sieht es meistens so aus wie der Inhalt von https://gist.github.com/kafene/5b4aa4ebbd9229fa2e73 )

Sie können konfigurieren sudo, dass mehrere Benutzer den mountBefehl ausführen können .

Update : Wie können Sie ein System durch die Montage beschädigen? Beispielsweise können Sie eine setuid-Root-Shell in einem Dateisystem erstellen, die Sie dann mounten und ausführen können, um Root-Berechtigungen zu erhalten.

Um Ihre Frage in Klammern zu beantworten: Da ein Dateisystem ein Platzhalter für Dateien ist, kann ein Benutzer möglicherweise schädliche Vorgänge auf diesem Dateisystem ausführen, z. B. Dateien löschen.

Zusammenfassend zu den beiden anderen Fragen sage ich Folgendes:

• fstaban ist für die Montage Boot - Zeit permanente Speicherung. Es ist nicht so toll, wenn Sie USB-Laufwerke anschließen oder gelegentlich einige Netzwerkfreigaben mounten möchten.

• sudo mountist auch in Ordnung, wenn Sie auf Ubuntu * -Systemen arbeiten. Sie müssen jedoch noch ein Kennwort eingeben.

• udev kümmert sich um die Montage von Dingen wie USB-Sticks, Kameras und Flash-Karten in Ubuntu * -Systemen (aber nicht in weniger benutzerfreundlichen Distributionen wie Debian, Slackware usw.)

Ich werde hinzufügen, dass die Unix-Möglichkeit, einigen Benutzern (oder Gruppen) die Berechtigung zu erteilen, Dinge zu tun, historisch gesehen über die sudoersDatei erfolgt.

Es gibt VIELE Anleitungen, um es dort draußen zu verwenden, also werde ich keine besonderen vorschlagen. Ich werde sagen, dass ich die Website des Linux-Dokumentationsprojekts verwendet habe, um mehr darüber zu erfahren.

Darüber hinaus sudoerskönnen Sie Geräte und Freigaben transparent bereitstellen - auch ohne Angabe eines Kennworts, wenn Sie dies wünschen (seien Sie dabei besonders vorsichtig).

In einer Steuerungsumgebung verwende ich normalerweise sudoersDatei, um Benutzern einer bestimmten Gruppe das transparente Mounten von Netzwerkfreigaben zu ermöglichen. Daher füge ich die Befehle mount.nfsund mount.cifsin die sudoers-Datei hinzu, die Vorgänge wie "Mounten des Basisordners eines Benutzers von einem Netzwerkdateiserver aus, wenn sich der Benutzer an einem Client-Terminal anmeldet" zulassen und so zu studieren.

guestmount libguestfs trickery

sudo apt-get install libguestfs-tools

# Workarounds for Ubuntu 18.04 bugs.
# https://serverfault.com/questions/246835/convert-directory-to-qemu-kvm-virtual-disk-image/916697#916697
sudo rm -rf /var/cache/.guestfs-*
echo dash | sudo tee /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/zz-dash-packages
sudo chmod +r /boot/vmlinuz-*

# Create a test image.
mkdir sysroot
dd if=/dev/urandom of=sysroot/myfile bs=1024 count=1024
virt-make-fs --format=raw --type=ext2 sysroot sysroot.ext2

# Mount it, have fun, unmount!
mkdir -p mnt
# /dev/sda becuase we have a raw filesystem.
guestmount -a sysroot.ext2.qcow2 -m /dev/sda mnt
cmp sysroot/myfile mnt/myfile
guestunmount mnt

Beruht auf:

• Userland-Implementierung der Dateisysteme
• SICHERUNG

Docs: http://libguestfs.org/guestmount.1.html

Getestet unter Ubuntu 18.04, libguestfs-tools 1: 1.36.13-1ubuntu3.