Comment autoriser les non-utilisateurs à monter n'importe quel système de fichiers?


48

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?"


Peutgvfs-mount-d /dev/sdX
KrisWebDev

Réponses:


46

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.


Merci pour votre réponse! BTW, pensez-vous qu'il est sécurisé de permettre aux utilisateurs du groupe mountde pouvoir monter des systèmes de fichiers comme le fait le compte root? Je vais lire le document sur les espaces de noms que vous avez lié et essayer d’implémenter cette idée de groupe de montage, au moins à titre d’exercice.

1
@derobert puisque vous parliez d'espaces de noms d'utilisateurs, vous pouvez consulter Plan 9 de Bell Labs (c'est le successeur d'UNIX, créé par les mêmes personnes). il modélise l'arborescence de fichiers comme un espace de noms par processus (et il n'y a rien de tel que root). trucs fascinants.
Strugee

1
@derobert Pouvons-nous obtenir une mise à jour de la section " L'espace de nommage d'un jour: espaces de noms d'utilisateurs "?
Malan

1
@malan OK, je l'ai mis à jour. Au contraire, je pense que l'utilisation d'espaces de noms d'utilisateurs pour cela semble être encore plus avancée dans le futur.
derobert le

1
@derobert Quelle tristesse. J'ai lu la réponse, vu que c'était en 2015, et j'ai pensé: "Je me demande si nous avons ceci maintenant!"
Malan

16

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.


1
C’est la seule réponse que je puisse trouver avec googler. J'ai découvert que sur FreeBSD, on peut autoriser les utilisateurs à monter des systèmes de fichiers en définissant une variable (à savoir vfs.usermount). Je veux qc analogue à cela. J'utilise beaucoup de lecteurs amovibles avec plusieurs partitions sur chacun et il serait fastidieux d'ajouter une douzaine ou deux entrées à fstab pour chacun d'eux.

La solution de rechange laide pourrait être de laisser udevgérer les entrées au fur et à mesure que de nouveaux appareils apparaissent et disparaissent.
Jester

Je n'ai pas trouvé que cela fonctionne sur Mint ou Ubuntu. Oui, le compte d'utilisateur par défaut peut être monté sans root, mais les utilisateurs 'standard' / 'desktop' ne peuvent pas le monter.
johny pourquoi

6

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

2
On dirait que la voie à suivre, mais n'a pas fonctionné pour moi.
Stéphane Gourichon

5

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. )


Seulement cela fonctionne dans les systèmes Debian, je ne sais pas pourquoi mettre des règles dans / etc / n'a pas fonctionné.
Anwar

Ne fonctionne pas sur l’extension Debian.
Philipp Ludwig

1
Fonctionne sur Debian Buster sur XFCE! Merci!
Maxwel Leite le

3

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.


J'ai pensé à cela, mais cela ne nécessitera-t-il pas que l'utilisateur exécute la commande avec sudo? En outre, n'est-ce pas l'utilisateur root qui monte le système de fichiers, uniquement en coulisse, avec cette méthode?

Oui, ils auraient besoin de sudo et oui, cela se ferait au nom de root. Pour résoudre le premier problème, vous pouvez alias mountpour sudo mountou utiliser un script d'emballage.
Bouffon

Ce que je voudrais, c’est monter le système de fichiers sans l’agence de l’utilisateur root. Masquer cette agence avec n'importe quoi n'est pas ce que je recherche du tout.

Notez que même l'ajout userà fstab ne fonctionne que parce qu'il mountest setuid root. Le noyau est à la recherche de root ou de CAP_SYS_ADMINcapacités, vous ne pouvez donc pas vraiment contourner root.
Jester

Vous pouvez configurer, comment? Cela n'aide pas.
Nuzzolilo

0

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.


1
Si vous utilisez sudo pour permettre à l'utilisateur de monter ses dossiers personnels lors de la connexion, vous devriez examiner autofs.
Derobert

Je les utilise ensemble. Je ne pouvais pas comprendre comment l'utiliser autofsseul pour monter /home/$USERle fichier depuis le serveur de fichiers, à l'emplacement situé /home/$USER/fromFS/sur le PC client.
vendredi

0

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.

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.