Est-il possible d'autoriser certains utilisateurs particuliers (par exemple les membres d'un groupe) à monter tout système de fichiers sans privilèges de superutilisateur sur Linux?
Une autre question aurait pu être "de quelles manières un utilisateur peut endommager un système en montant des systèmes de fichiers?"
Il existe quelques approches, certaines d'entre elles étant pour la plupart sécurisées, d'autres pas du tout.
Laissez toute utilisation s'exécuter mount
, par exemple via Sudo. Vous pourriez aussi bien leur donner racine; c'est la même chose. L'utilisateur peut monter un système de fichiers avec une copie racine suid de bash
— en cours d'exécution qui donne instantanément root (probablement sans aucune journalisation, au-delà du fait que mount
a été exécuté).
Alternativement, un utilisateur pourrait monter son propre système de fichiers sur /etc
, contenant sa propre copie de /etc/shadow
ou /etc/sudoers
, puis obtenez root avec su
ou 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 /etc/pam.d
et bien d'autres endroits.
N'oubliez pas que les systèmes de fichiers n'ont même pas besoin d'être sur un périphérique, -o loop
montera un fichier appartenant (et donc modifiable) à l'utilisateur.
Les divers environnements de bureau ont en fait déjà conçu des solutions pour permettre aux utilisateurs de monter des supports amovibles. Ils fonctionnent en montant dans un sous-répertoire de /media
uniquement et en désactivant la prise en charge de set-user/group-id via les options du noyau. Les options ici incluent 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 en écrivant ce script pour ne pas laisser d'exploits root. Si vous ne voulez pas que vos utilisateurs se souviennent de Sudo, vous pouvez faire quelque chose comme ça dans un script:
#!/bin/bash
if [ $UID -ne 0 ]; then # or `id -u`
exec Sudo -- "$0" "$@"
fi
# rest of script goes here
Les espaces de noms Linux sont une forme de virtualisation très légère (conteneurs, pour être plus précis). En particulier, avec les espaces de noms des 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 qu'il a été explicitement bloqué, à l'exception de quelques systèmes de fichiers virtuels. Finalement, les systèmes de fichiers Fuse seront probablement autorisés, mais les derniers correctifs que j'ai pu trouver ne couvrent pas les périphériques bloqués, seulement des choses comme sshfs.
En outre, de nombreux noyaux de distribution ont (pour des raisons de sécurité) par défaut de ne pas autoriser les utilisateurs non privilégiés à utiliser les espaces de noms des utilisateurs; par exemple Debian a un kernel.unprivileged_userns_clone
par défaut à 0. D'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 des utilisateurs est un article LWN Les espaces de noms en fonctionnement, partie 5: Les espaces de noms des utilisateurs .
Pour l'instant, j'irais avec udisks2.
Vous pouvez le faire, mais vous devez modifier l'entrée dans /etc/fstab
correspondant au système de fichiers que vous souhaitez monter, en ajoutant le drapeau user
à cette entrée. Les utilisateurs sans privilèges pourraient alors le monter.
Voir man mount
pour plus de détails.
Ici est le wiki pour configurer polkit les règles 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 soyez 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
Sur Xubuntu, il fonctionne dès le départ pour monter et éjecter le stockage de masse USB, les partitions de disque dur, les CD/DVD et probablement plus encore.
Supposons que la solution choisie par Ubuntu, en utilisant policyKit, soit suffisamment sécurisée.
Sur XFCE sur Debian 8.3, je devais permettre à l'utilisateur de monter et d'éjecter des systèmes de fichiers de thunar sans mot de passe. Ce qui a fonctionné pour moi, c'est de choisir un fichier d'autorisation d'Ubuntu.
Ajout des lignes ci-dessous en tant que root à un fichier nommé /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla
devrait 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
(Ce que j'ai fait en fait, c'est de choisir un peu plus dans le fichier du même nom sur Ubuntu 16.04 et cela a fonctionné pour moi. Si vous en avez besoin, il ressemble principalement au contenu de https://Gist.github.com/kafene/5b4aa4ebbd9229fa2e7 )
Vous pouvez configurer Sudo
pour permettre à un ensemble d'utilisateurs d'exécuter la commande mount
.
Mise à jour: comment endommager un système en le montant? Par exemple, vous pouvez créer un shell racine setuid sur un système de fichiers que vous pouvez ensuite monter et exécuter pour obtenir les privilèges root.
Recherchez le groupe d'appareil auquel appartient le fichier
ls -l /dev/sda2
brw-rw---- 1 root disk /dev/sda2
Vu que le fichier de périphérique appartient au groupe disk
Ajoutez maintenant notre utilisateur au groupe disk
usermod -G disk -a username
Et maintenant dans /etc/fstab
/dev/sda2 /mnt/backups ext4 noauto,group,suid,dev,async 0 2
ou avec UUID
UUID=c90324c1-3fba-119c-913c-5f913afdca8b /mnt/backups ext4 noauto,group,suid,dev,async 0 2
Maintenant, tous les utilisateurs du groupe disk
, pour l'instant c'est seulement username
, peuvent monter certains disques.
Pour répondre à votre question entre parenthèses, puisqu'un système de fichiers est un espace réservé pour les fichiers, un utilisateur peut potentiellement effectuer des opérations nuisibles sur ce système de fichiers, telles que supprimer des fichiers.
Résumant les 2 autres questions, je dirai ceci:
fstab
est idéal pour un montage à boot time permanent stockage. Ce n'est pas très bien lorsque vous souhaitez brancher des lecteurs USB ou monter occasionnellement des partages réseau.
Sudo mount
est également correct si vous utilisez des systèmes ubuntu *. Vous devrez cependant saisir un mot de passe.
udev
se chargera de monter des choses comme des clés USB, des caméras et des cartes flash dans les systèmes ubuntu * (mais pas dans des distributions moins conviviales comme debian, slackware, etc.)
J'ajouterai que, historiquement, la façon Unix de donner à certains utilisateurs (ou groupes) le pouvoir de faire des choses est via le fichier sudoers
.
Il existe de nombreux guides pour l'utiliser, donc je ne proposerai aucun détail. Je dirai que j'ai utilisé le site Web du projet de documentation Linux pour en savoir plus.
De plus, avec sudoers
, vous 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 (soyez très prudent à ce sujet).
Ce que je fais habituellement dans un environnement de contrôle, c'est que j'utilise le fichier sudoers
pour permettre aux utilisateurs d'un certain groupe de monter des partages réseau de manière transparente. J'ajoute donc les commandes mount.nfs
et mount.cifs
dans le fichier sudoers qui autorise 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 se connecte à 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:
Documents: http://libguestfs.org/guestmount.1.html
Testé sur Ubuntu 18.04, libguestfs-tools 1: 1.36.13-1ubuntu3.