Безпечно користуйтеся знахідкою із судо

На сервері Linux мені потрібно видалити root права з групи користувачів. Але ці користувачі мають законні причини, щоб мати можливість використовувати утиліту "знайти" для пошуку файлів на основі імен файлів, дати модифікації та інших метаданих.

На сервері імена файлів не чутливі, але вміст файлу може бути.

Я хотів би використовувати sudo, щоб дозволити користувачам шукати файли в будь-якому місці сервера. Утиліта "знайти" чудова, але вона дозволяє використовувати всі види побічних ефектів, наприклад використання "-exec" для нересурсу довільних команд.

Чи можу я findпрацювати з обмеженнями?

А як же знайти ?

locate зчитує одну або більше баз даних, підготовлених updateb (8), і записує імена файлів, що відповідають принаймні одному з PATTERN стандартному виводу, по одному на рядок. Якщо --regex не вказано, PATTERN можуть містити символи глобалізації. Якщо будь-який PATTERN не містить символів глобалізації, знайдіть поведінку так, ніби шаблон був PATTERN .

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

Або, можливо, навіть розмістити :

Безпечний пошук - це безпечний спосіб індексувати та швидко шукати файли у вашій системі. Він використовує інкрементальне кодування так само, як GNU locate, щоб стиснути свою базу даних для швидшого пошуку, але він також зберігатиме дозволи та права власності на файли, щоб користувачі не бачили файли, до яких вони не мають доступу.

Ця сторінка керівництва документує GCU-версію слокату. slocate Дозволяє користувачам системи шукати всі файлові системи без відображення несанкціонованих файлів.

Згідно з man 7 capabilities

   CAP_DAC_READ_SEARCH
          * Bypass file read permission checks and directory read and execute permission checks;
          * Invoke open_by_handle_at(2).

Це працювало для мене. (рядки, що починаються з "#", є кореневими, а рядки з "$" - некореневими) wheel.

# cp /usr/bin/find /usr/bin/sudofind
# chmod 710 /usr/bin/sudofind
# chown root:wheel /usr/bin/sudofind
# setcap cap_dac_read_search+ep /usr/bin/sudofind
# exit
$ find /root 
find: ‘/root’: Permission denied
$ sudofind /root
/root /root 
/root/Testbed 
...
... 
$ sudofind /root -exec cat {} \;
cat: /root: Permission denied 
cat: /root/Testbed: Permission denied
$ sudofind /root -printf "%u %g %m %c %p\n"
root root 644 Mon Apr 20 09:20:48.0457518493 2015 /root
root root 755 Fri Dec  4 02:34:03.0016294644 2015 /root/Testbed
...
...
$ # Capability inheritance test..
$ sudofind /root -exec /bin/sleep 10 \; &
[1] 17017
$ getpcaps $(pgrep find)
Capabilities for `17017': = cap_dac_read_search+ep
$ getpcaps $(pgrep sleep)
Capabilities for `17019': =

З огляду на те, що надає можливість, вона точно відповідає тому, що ви хочете. Я не вичерпно перевіряв, чи findє така функція, яка дозволяє читати байти всередині файлів, але очевидні речі, такі як LD_PRELOADатаки на бібліотечні shim, не повинні працювати через характер встановлених перевірок у Linux, і біти можливостей не отримують успадковується або дочірніми процесами (на відміну від сирої програми), тому це ще один бонус.

Майте на увазі, що те, що ви хочете зробити, викликає можливі занепокоєння щодо конфіденційності щодо створення тимчасових файлів або доступу, і програма може бути використана як основа для встановлення перегонової умови / спроби ескалації привілеїв (проти програм, які створюють відомі назви файлів але не робіть правильних перевірок безпеки).

Також деякі погано написані програми можуть покладатися на метадані файлів або структуру дерева як спосіб передати значення або приховати дані. Це може спричинити випуск інформації з обмеженим доступом або виявити привілейовані документи, про які інакше не відомо (безпека через незрозумілість я знаю, але, на жаль, це те, що, зокрема, люблять робити постачальники із закритим кодом).

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

О, і мені було б цікаво подивитися, чи є у когось доказ концептуальної атаки, який використовує цей механізм як основу для ескалації привілеїв у коментарях!

Я б дав користувачам належні дозволи.

За замовчуванням, якщо є umask 022, створюються каталоги, щоб кожен міг перераховувати та статувати файли в них. Якщо ні, ви можете вручну змінити дозвіл каталогу на бітовий або його старі дозволи та 0555:

chmod +0555 foo

І якщо ці користувачі не мають дозволу на виконання всіх батьків цього каталогу (наприклад, домашнього каталогу іншого користувача), це, ймовірно, означає, що ви повинні покласти перший каталог десь в іншому місці.

Якщо ви хочете лише дозволити деяким користувачам читати та виконувати цей каталог, ви можете змінити його режим 0750, розмістити цих користувачів у групі та змінити власника групи каталогу на цю групу:

groupadd can_read_foo
chmod 0750 foo
chgrp can_read_foo foo
gpasswd -a alice can_read_foo
gpasswd -a bob can_read_foo