Як дозволити не-суперпользователям монтувати будь-яку файлову систему?


47

Чи можна дозволити деяким конкретним користувачам (наприклад, членам групи) монтувати будь-яку файлову систему без привілеїв суперпользователя в Linux?

Інше питання, можливо, було "в який спосіб користувач може завдати шкоди системі, встановивши файлові системи?"


Можливоgvfs-mount-d /dev/sdX
KrisWebDev

Відповіді:


44

Є кілька підходів, деякі з них переважно захищені, інші - зовсім не такі.

Невпевнений спосіб

Нехай будь-яке використання працює mount, наприклад, через sudo. Ви можете також дати їм корінь; це те саме. Користувач може змонтувати файлову систему з копією кореневої копії bash—запуск, який миттєво дає корінь (швидше за все, без будь-якого журналу, поза фактом, що mountбув запущений).

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

Подібні напади можуть бути зняті /etc/pam.dі над багатьма іншими місцями.

Пам'ятайте, що файлові системи навіть не повинні бути на пристрої, вони -o loopзможуть змонтувати файл, який належить користувачеві (і, таким чином, змінюється).

Здебільшого безпечний спосіб: удиски чи подібні

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

Якщо потрібно, ви можете написати свій власний сценарій, щоб зробити щось подібне, і викликати його через 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: Простори імен користувачів .

Поки б я пішов з удисками2.


Дякую за вашу відповідь! BTW, чи вважаєте ви, що це безпечно, щоб дозволити користувачам у групі mountзмогу монтувати файлові системи, як root? Я прочитаю документ про простори імен, який ви пов’язали, і спробую реалізувати цю групу монтування, принаймні як вправу.

@gkya Я сподіваюся, що в моєму першому розділі було зрозуміло, що дозволяють (а) монтувати файлову систему без примушування nosuid [а також nodev]; або (b) в довільному місці в основному дає корінь. Якщо ви даєте комусь дозвіл на виконання довільних mountкоманд, це те саме, що давати root.
derobert

@gkya з ваших "багатьох знімних дисків з багатьма розділами на кожен" прокоментуйте іншу відповідь, я б припустив, що ви хочете "удиски чи подібний" підхід.
дероберт

1
@derobert, оскільки ви говорили про простори імен користувачів, ви можете перевірити План 9 від Bell Labs (це наступник UNIX, створений тими ж людьми). воно моделює дерево файлів як простір імен за кожним процесом (і немає такого поняття, як root). захоплюючі речі.
strugee

1
@malan ОК, я оновив його. Якщо що, я думаю, що використання просторів імен користувачів для цього виглядає ще більше в майбутньому.
дероберт

16

Ви можете це зробити, але вам потрібно змінити запис /etc/fstabвідповідно до файлової системи, яку ви хочете встановити, додавши прапор userдо цього запису. Користувачі, які не мають пільг, зможуть це встановити.

Дивіться man mountдокладнішу інформацію.


1
Це єдина відповідь, яку я можу знайти в Google. Я з'ясував, що на FreeBSD можна дозволити користувачам монтувати файлові системи із встановленням змінної (а саме vfs.usermount). Я хочу що-небудь. аналогічний тому. Я використовую багато знімних накопичувачів з багатьма розділами на кожному, і було б громіздко додати десяток-два записи для fstab для кожного з них.

Некрасивим рішенням може бути дозволити udevкерувати записами у міру появи та зникнення нових пристроїв.
Jester

я не знайшов, щоб це працювало на монетному дворі або Ubuntu. Так, обліковий запис користувача за замовчуванням може працювати без кореня, але користувачі "стандартного" / "робочого столу" не можуть його встановити.
Джоні, чому

6

Ось вікі для налаштування 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

2
Здається, дорога, але мені не вийшло.
Стефан Гурішон

5

1 Подивіться, де це працює

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

Припустимо, що рішення, яке Ubuntu обрав, використовуючи policyKit, є досить безпечним.

2 Виберіть відповідну частину

На XFCE на Debian 8.3 мені потрібно було дозволити користувачеві монтувати та видаляти файлові системи з тунару без пароля. Що для мене працювало - це вибрати файл дозволу від Ubuntu.

Додавання рядків нижче як корінь до імені файлу /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 )


Тільки це працює в системах, подібних до debian, не знаю, чому ставити правила на / etc / не вийшло.
Анвар

Не працює на розтягуванні debian.
Філіпп Людвіг

1
Працює над Debian Buster на XFCE! Дякую!
Maxwel Leite

3

Ви можете налаштувати, sudoщоб дозволити набору користувачів виконувати mountкоманду.

Оновлення : як можна пошкодити систему шляхом монтажу? Наприклад, ви можете створити встановлену кореневу оболонку у файловій системі, яку потім зможете змонтувати та виконати для отримання привілеїв root.


Я подумав про це, але чи не вимагає від цього користувача запустити команду sudo? Крім того, хіба це кореневий користувач, який монтує файлову систему, лише за кадром, цим методом?

Так, їм буде потрібно судо, і так, він би запускався від імені root. Для вирішення першої проблеми, ви могли б псевдонім , mountщоб sudo mountабо використовувати сценарій оболонки.
Єстер

Що я хотів би мати - це монтувати файлову систему без агента root користувача. Маскування цього агентства нічим - це не те, про що я взагалі.

Зауважте, що навіть додавання userдо fstab працює лише тому, що mountце встановлений корінь. Ядро перевіряє наявність кореня або CAP_SYS_ADMINможливості, тому ви не можете дійсно обійти участь із залученням root.
Єстер

Ви можете налаштувати, як? Це не допомагає.
Нуццоло

0

Щоб відповісти на ваше запитання в дужках, оскільки файлова система є заповнювачем файлів, користувач може потенційно виконувати шкідливі операції в цій файловій системі, такі як видалення файлів.

Підсумовуючи інші 2 запитання, я скажу так:

  • fstabчудово підходить для монтажу під час завантаження постійного зберігання. Це не так здорово, коли ви хочете підключити usb-накопичувачі або інколи монтувати деякі спільні мережі.

  • sudo mountтакож добре, якщо ви працюєте в системах ubuntu *. Вам все одно потрібно буде ввести пароль.

  • udev подбає про встановлення таких речей, як USB-палички, камери та флеш-карти в системах ubuntu * (але не в менш зручних дистрибутивах, таких як debian, slackware тощо)

Додам, що історично єдиний спосіб надати повноваження деяким користувачам (або групам) робити речі - це через sudoersфайл.

Є багато посібників, щоб використовувати його там, тому я не пропоную жодного конкретного. Скажу, що я використовував веб-сайт проекту документації Linux, щоб дізнатися про нього.

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

Що я зазвичай роблю в середовищі управління, - це я використовую sudoersфайл, щоб дозволити користувачам певної групи прозоро монтувати мережеві спільні доступу. Тож я додаю команди mount.nfsта mount.cifsу файл sudoers, що дозволяють виконувати такі операції, як "встановити домашню папку користувача з сервера мережевих файлів, коли користувач увійде в клієнтський термінал" і виконуються так.


1
Якщо ви використовуєте sudo, щоб дозволити користувачеві монтувати свої домашні папки при вході в систему, вам слід переглянути авто.
дероберт

Я використовую їх разом; Я не міг зрозуміти, як використовувати autofsсамостійно для монтажу /home/$USERфайлового сервера до місця розташування /home/$USER/fromFS/на клієнтському ПК.
nass

0

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

Спирається на:

  • реалізація файлових систем користувача
  • ЗАПИТИВ

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

Тестовано на Ubuntu 18.04, libguestfs-інструменти 1: 1,36,13-1ubuntu3.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.