Назад | Перейти на главную страницу

Безопасно используйте find с sudo

На сервере Linux мне нужно удалить привилегии root у группы пользователей. Но у этих пользователей есть законные основания использовать утилиту «find» для поиска файлов по именам файлов, датам модификации и другим метаданным.

На сервере имена файлов не важны, но может быть и содержимое файла.

Я хотел бы использовать sudo, чтобы пользователи могли искать файлы в любом месте на сервере. Утилита «find» великолепна, но она допускает всевозможные побочные эффекты, такие как использование «-exec» для создания произвольных команд.

Можно взять find работать с моими ограничениями?

В соответствии с 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).

Это сработало для меня. (строки, начинающиеся с '#', являются корневыми, те, что с '$', не являются корневыми) в этом случае пользователь без полномочий root находится в 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 и атаки с использованием совместимости библиотеки не должны работать из-за природы проверок setuid в Linux, а биты возможностей также не наследуются дочерними процессами (в отличие от raw setuid), так что это еще один бонус.

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

Кроме того, некоторые плохо написанные приложения могут полагаться на метаданные файлов или древовидную структуру как способ передать смысл или скрыть данные. Это может привести к раскрытию информации с ограниченным доступом или раскрытию привилегированных документов, о которых иным образом не известно (безопасность через неясность я знаю, но, к сожалению, это особенно нравится делать поставщикам закрытых исходных кодов).

Поэтому будьте осторожны и будьте осторожны с этим и поймите, что все еще существует риск, связанный с этим, даже если очевидные вещи не работают.

О, и мне было бы интересно узнать, есть ли у кого-то доказательство концепции атаки, которая использует этот механизм в качестве основы для повышения привилегий в комментариях!

Что о найти?

locate читает одну или несколько баз данных, подготовленных updatedb (8), и записывает имена файлов, соответствующие хотя бы одному из ШАБЛОНОВ, в стандартный вывод, по одному в каждой строке. Если --regex не указан, ШАБЛОН может содержать символы подстановки. Если какой-либо ШАБЛОН не содержит символов подстановки, locate ведет себя так, как если бы шаблон был ШАБЛОН.

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

А может даже размещать:

Secure Locate обеспечивает безопасный способ индексирования и быстрого поиска файлов в вашей системе. Он использует инкрементное кодирование, как и GNU locate, для сжатия своей базы данных, чтобы ускорить поиск, но также сохраняет права доступа к файлам и права собственности, чтобы пользователи не видели файлы, к которым у них нет доступа.

Эта страница руководства документирует GNU-версию slocate. slocate Позволяет пользователям системы искать целые файловые системы без отображения неавторизованных файлов.

Я бы дал пользователям соответствующие разрешения.

По умолчанию, если 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