Est-il possible d'autoriser certains utilisateurs particuliers (par exemple, les membres d'un groupe) à monter un système de fichiers sans privilèges de superutilisateur sur Linux?

Une autre question aurait pu être "de quelle manière un utilisateur peut nuire à un système en installant des systèmes de fichiers?"

Il existe plusieurs approches, certaines sécurisées pour la plupart, d’autres pas du tout.

La voie précaire

Laissez toute utilisation s'exécuter mount, par exemple, à travers sudo. Vous pourriez aussi bien leur donner la racine; c'est la même chose. L'utilisateur peut monter un système de fichiers avec une copie racine suid de - une bashexécution qui donne instantanément la racine (probablement sans aucune journalisation, au-delà du fait qu'elle a mountété exécutée).

Alternativement, un utilisateur peut monter son propre système de fichiers sur /etc, contenant sa propre copie de /etc/shadowou /etc/sudoers, puis obtenir la racine avec suou sudo. Ou éventuellement bind-mount ( mount --bind) sur l'un de ces deux fichiers. Ou un nouveau fichier dans /etc/sudoers.d.

Des attaques similaires pourraient être menées sur de /etc/pam.dnombreux autres endroits.

Rappelez-vous que les systèmes de fichiers n'ont même pas besoin d'être sur un périphérique, -o loopmontera un fichier qui appartient (et donc est modifiable) à l'utilisateur.

Le moyen le plus sûr: udisks ou similaire

Les divers environnements de bureau ont en fait déjà élaboré des solutions pour permettre aux utilisateurs de monter des supports amovibles. Ils fonctionnent en montant dans un sous-répertoire de /mediaonly et en désactivant la prise en charge de set-user / group-id via les options du noyau. Les options incluent ici udisks, udisks2, pmount, usbmount,

Si vous le devez, vous pouvez écrire votre propre script pour faire quelque chose de similaire et l'invoquer via sudo - mais vous devez être très prudent lors de l'écriture de ce script pour ne pas laisser d'exploits root. Si vous ne voulez pas que vos utilisateurs aient à se souvenir de sudo, vous pouvez faire quelque chose comme ceci dans un script:

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

# rest of script goes here 

Le moyen du jour d'être sécurisé: les espaces de noms d'utilisateurs

Les espaces de noms Linux sont une forme très légère de virtualisation (des conteneurs, pour être plus spécifique). En particulier, avec les espaces de noms d'utilisateurs, tout utilisateur du système peut créer son propre environnement dans lequel il est root. Cela leur permettrait de monter des systèmes de fichiers, sauf que ceux-ci ont été explicitement bloqués, à l'exception de quelques systèmes de fichiers virtuels. Finalement, les systèmes de fichiers FUSE seront probablement autorisés, mais les correctifs les plus récents que j'ai trouvés ne couvrent pas les périphériques en mode bloc, mais uniquement des choses comme sshfs.

En outre, de nombreux noyaux de distribution ont (pour des raisons de sécurité) par défaut, empêché les utilisateurs non privilégiés d'utiliser les espaces de noms d'utilisateurs; Par exemple, Debian a une valeur kernel.unprivileged_userns_clonepar défaut de 0. Les autres distributions ont des paramètres similaires, bien que souvent avec des noms légèrement différents.

La meilleure documentation que je connaisse sur les espaces de noms d'utilisateurs est un article de LWN intitulé Espaces de noms en opération, partie 5: Espaces de noms d'utilisateurs .

Pour l'instant, j'irais avec udisks2.

Vous pouvez le faire, mais vous devez modifier l'entrée en fonction /etc/fstabdu système de fichiers que vous souhaitez monter, en ajoutant l'indicateur userà cette entrée. Les utilisateurs non privilégiés pourraient alors le monter.

Voir man mountpour plus de détails.

Voici le wiki pour la configuration des règles polkit pour udisks / udisks2 afin de monter des partitions par groupe non root (par exemple, utilisateurs).

Enregistrez le code ci-dessous dans /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];
  }
});

Supposons que vous êtes dans le groupe "utilisateurs", en utilisant la commande suivante pour monter une partition (pas besoin de sudo).

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

# udisks
udisks --mount /dev/sda1

1 Regarde où ça marche

Sous Xubuntu, le montage et l’éjection du stockage de masse USB, des partitions de disque dur, des CD / DVD et bien d’autres encore est une solution immédiate.

Supposons que la solution choisie par Ubuntu, à l'aide de policyKit, soit suffisamment sécurisée.

2 Choisissez la partie pertinente

Sous XFCE sous Debian 8.3, je devais permettre à l’utilisateur de monter et d’éjecter les systèmes de fichiers de thunar sans mot de passe. Ce qui a fonctionné pour moi est de sélectionner un fichier de permission d’Ubuntu.

Ajouter les lignes ci-dessous en tant que root à un fichier nommé /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkladevrait faire l'affaire:

[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 Profit!

(En réalité, j'ai choisi un peu plus du fichier portant le même nom sous Ubuntu 16.04 et cela a fonctionné pour moi. Si vous en avez besoin, le contenu de https://gist.github.com/kafene/5b4aa4ebbd9229fa2e73 apparaît généralement. )

Vous pouvez configurer sudopour autoriser un ensemble d'utilisateurs à exécuter la mountcommande.

Mise à jour : comment endommager un système en montant? Par exemple, vous pouvez créer un shell root setuid sur un système de fichiers que vous pouvez ensuite monter et exécuter pour obtenir les privilèges root.

Pour répondre à votre question entre parenthèses, puisqu'un système de fichiers est un espace réservé pour des fichiers, un utilisateur peut potentiellement effectuer des opérations nuisibles sur ce système de fichiers, telles que la suppression de fichiers.

Résumant les 2 autres questions, je dirai ceci:

• fstabest idéal pour le montage au démarrage du temps permanent de stockage. Ce n’est pas très bien quand vous voulez brancher des lecteurs USB ou monter occasionnellement des partages réseau.

• sudo mountest également correct si vous êtes sur des systèmes Ubuntu *. Vous devrez néanmoins saisir un mot de passe.

• udev se chargera de monter des éléments tels que des clés USB, des appareils photo et des cartes flash dans les systèmes Ubuntu * (mais pas dans les distributions moins conviviales comme debian, slackware, etc.)

J'ajouterai qu'historiquement, le moyen unix de donner à certains utilisateurs (ou groupes) le pouvoir de faire des choses est d'utiliser le sudoersfichier.

Il existe de nombreux guides pour l'utiliser, donc je ne suggérerai aucun particulier. Je dirai que j'ai utilisé le site Web du projet de documentation Linux pour en apprendre davantage à ce sujet.

De plus, sudoersvous pouvez monter des périphériques et des partages de manière transparente, même sans fournir de mot de passe si vous le souhaitez (faites très attention à ce sujet).

Ce que je fais généralement dans un environnement de contrôle, c’est que j’utilise un sudoersfichier pour permettre aux utilisateurs de certains groupes de monter des partages réseau de manière transparente. J'ajoute donc les commandes mount.nfset mount.cifsle fichier sudoers autorisant des opérations telles que "monter le dossier de départ de l'utilisateur à partir d'un serveur de fichiers réseau, lorsque l'utilisateur ouvre une session sur un terminal client" et studd comme ça.

guestmount ruse libguestfs

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

Repose sur:

• implémentation des systèmes de fichiers en mode utilisateur
• FUSIBLE

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

Testé sur Ubuntu 18.04, libguestfs-tools 1: 1.36.13-1ubuntu3.