Можно ли разрешить некоторым конкретным пользователям (например, членам группы) монтировать любую файловую систему без привилегий суперпользователя в Linux?

Другой вопрос мог заключаться в том, «каким образом пользователь может повредить систему, монтируя файловые системы?»

Есть пара подходов, некоторые из них в основном безопасны, другие совсем нет.

Небезопасный путь

Пусть любое использование запускается mount, например, через sudo. Вы могли бы также дать им корень; это то же самое. Пользователь может смонтировать файловую систему с suid-корневой копией - bashruning, которая мгновенно дает root (скорее всего, без какой-либо регистрации, помимо факта, который mountбыл запущен).

Кроме того, пользователь может смонтировать свою собственную файловую систему поверх /etc, содержащую его / ее собственную копию /etc/shadowили /etc/sudoers, а затем получить root с помощью либо suили sudo. Или, возможно, bind-mount ( mount --bind) для одного из этих двух файлов. Или новый файл в /etc/sudoers.d.

Подобные атаки могут быть осуществлены /etc/pam.dи во многих других местах.

Помните, что файловые системы даже не должны быть на устройстве, они -o loopбудут монтировать файл, который принадлежит (и, следовательно, может быть изменен) пользователем.

Наиболее безопасный способ: удиски или аналогичные

В различных средах рабочего стола уже созданы соответствующие решения, позволяющие пользователям монтировать съемные носители. Они работают, монтируя только в подкаталоге /mediaи отключая поддержку set-user / group-id через параметры ядра. Варианты здесь включают udisks, udisks2, pmount, usbmount,

Если вам необходимо, вы можете написать свой собственный скрипт для выполнения чего-то подобного и вызывать его через sudo, но вы должны быть очень осторожны при написании этого скрипта, чтобы не оставить корневых эксплойтов. Если вы не хотите, чтобы ваши пользователи помнили sudo, вы можете сделать что-то подобное в скрипте:

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

# rest of script goes here 

Когда-нибудь мы будем в безопасности: пространства имен пользователей

Пространства имен Linux - это очень легкая форма виртуализации (контейнеры, если быть более точным). В частности, с пространствами имен пользователей любой пользователь в системе может создать свою собственную среду, в которой он является пользователем root. Это позволило бы им монтировать файловые системы, за исключением явно заблокированных, за исключением нескольких виртуальных файловых систем. В конце концов, файловые системы FUSE, вероятно, будут разрешены, но самые последние исправления, которые я смог найти , не охватывают блочные устройства, а только такие вещи, как sshfs.

Кроме того, во многих ядрах дистрибутивов (по соображениям безопасности) по умолчанию не разрешено непривилегированным пользователям использовать пространства имен пользователей; например, Debian имеет значение по kernel.unprivileged_userns_cloneумолчанию 0. Другие дистрибутивы имеют аналогичные настройки, хотя часто с немного другими именами.

Лучшая документация, которую я знаю о пространствах имен пользователей, - статья LWN « Пространства имен в действии», часть 5: Пространства имен пользователей .

Сейчас я бы пошел с udisks2.

Вы можете сделать это, но вам нужно изменить запись в /etc/fstabсоответствии с файловой системой, которую вы хотите смонтировать, добавив флаг userк этой записи. Пользователи без привилегий смогут его смонтировать.

Смотрите man mountдля более подробной информации.

Вот вики для настройки правил polkit для udisks / udisks2 для монтирования разделов по некорневой (например, по пользователям) группе.

Сохраните код ниже в /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];
  }
});

Предположим, вы находитесь в группе «пользователи», используя следующую команду для монтирования раздела (нет необходимости sudo).

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

# udisks
udisks --mount /dev/sda1

1 Посмотри где это работает

В Xubuntu он работает из коробки для установки и извлечения запоминающего устройства USB, разделов жесткого диска, CD / DVD-дисков и, возможно, многого другого.

Давайте предположим, что решение, выбранное Ubuntu с использованием policyKit, является достаточно безопасным.

2 Выберите соответствующую часть

На XFCE на Debian 8.3 мне нужно было разрешить пользователю монтировать и извлекать файловые системы из thunar без пароля. То, что сработало для меня, это выбрать файл разрешения в Ubuntu.

Добавление строк ниже как root к файлу с именем /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pklaдолжно помочь:

[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 Прибыль!

(На самом деле я выбрал немного больше из файла с тем же именем в Ubuntu 16.04, и он сработал для меня. Если вам это нужно, он в основном похож на содержимое https://gist.github.com/kafene/5b4aa4ebbd9229fa2e73 )

Вы можете настроить, sudoчтобы набор пользователей мог запускать mountкоманду.

Обновление : как можно повредить систему при монтаже? Например, вы можете создать корневую оболочку setuid в файловой системе, которую затем можно смонтировать и выполнить для получения привилегий root.

Чтобы ответить на ваш вопрос в скобках, поскольку файловая система является заполнителем для файлов, пользователь может потенциально выполнять вредоносные операции с этой файловой системой, такие как удаление файлов.

Подводя итог двум другим вопросам, я скажу следующее:

• fstabотлично подходит для монтажа во время загрузки постоянного хранения. Это не так здорово, когда вы хотите подключить USB-накопители или иногда подключать некоторые сетевые ресурсы.

• sudo mountтакже хорошо, если вы работаете в системах Ubuntu *. Вам все равно нужно будет ввести пароль.

• udev позаботится о монтировании таких вещей, как USB-флешки, камеры и флэш-карты в системах Ubuntu * (но не в менее удобных для пользователя дистрибутивах, таких как Debian, Slackware и т. д.)

Я добавлю, что исторически Unix-способ дать полномочия некоторым пользователям (или группам) делать что-либо - через sudoersфайл.

Есть много руководств, чтобы использовать его там, поэтому я не буду предлагать какие-либо конкретные. Я скажу, что я использовал сайт проекта документации Linux, чтобы узнать об этом.

Более sudoersтого, вы можете прозрачно монтировать устройства и общие ресурсы - даже без указания пароля, если вы решите это сделать (будьте особенно внимательны).

В контрольной среде я обычно использую sudoersфайл, чтобы позволить пользователям определенной группы прозрачно монтировать сетевые ресурсы. Поэтому я добавил команды mount.nfsи mount.cifsв файл sudoers, который разрешает такие операции, как «монтирование домашней папки пользователя с сетевого файлового сервера, когда пользователь входит в систему на клиентском терминале», и так изучаю.

guestmount Обман 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

Полагается на:

• пользовательская реализация файловых систем
• FUSE

Документы: http://libguestfs.org/guestmount.1.html

Протестировано на Ubuntu 18.04, libguestfs-tools 1: 1.36.13-1ubuntu3.