Intereting Posts
Согласованный и безопасный подход к учетным записям без пароля в SSH Как автоматически добавить ключевой файл и кодовую фразу в ssh-agent? Как я могу отредактировать мой скрипт bash для учета пробелов? Как отслеживать жизненный цикл потоков ядра, следуя созданию и переключению? Команда Bash останавливается и не выполняет третью часть Automake – проблема с установкой версии automake-1.14.1 Как извлечь текущую ревизию из каталога репозиториев SVN (subversion) + файлов Почему ping требует разрешения setuid? как заставить XTerm никогда не использовать жирные символы? Как переместить окно в другое рабочее пространство в Xfce? «Permission denied» даже с набором uid / gid / umask (NTFS) Скопируйте текстовые строки из файла и добавьте их в один и тот же файл с префиксом средней линии или удалите префикс средней строки Сопоставление привязок клавиш Как изменить время BIRTH файла BSD (aka btime)? Могут ли две асинхронные команды подзаголовки безопасно записываться в общий stdout?

Почему chroot (2) недоступен для непривилегированных пользователей?

Почему chroot(2) недоступен для непривилегированных пользователей?

Я не понимаю существующих ответов в Интернете. Например, это https://lists.freebsd.org/pipermail/freebsd-security/2003-April/000123.html .

Будет ли sudo действительно работать, если /etc/sudoers и /etc не принадлежат root? Непривилегированный пользователь не может просто создавать корневые двоичные файлы setuid внутри chroot, не так ли?

Как именно непривилегированный пользователь может подорвать среду chroot?

Я могу только думать о чем-то подобном

 ln /mnt/backup/XYZ/etc/sudoers $CHROOT/etc/sudoers ln /usr/bin/sudo $CHROOT/usr/bin/sudo 

где XYZ обозначает некоторый экземпляр резервной копии, где администратор действительно напортачил и позволил моему пользователю что-то опасное. Но это нечто особенное. Есть ли более простой способ использовать chroot(2) если он доступен для непривилегированных пользователей?

Обычный пользователь не может создать двоичный файл setuid, но ничего не мешает ему создать жесткую ссылку на существующий двоичный файл setuid. Поэтому, если у него есть разрешение на запись в каталог в той же файловой системе, что и /usr/bin , он может поместить тюрьму в этот каталог, создать жесткую ссылку на su или sudo в ней и поставить пользовательский /etc/passwd и /etc/sudoers в тюрьме.

Возможно, это не сработает для sudo , так как это может проверить, что /etc/sudoers принадлежит root. Но я готов поспорить, что su не проверяет право собственности на /etc/passwd .

Согласно Брэду Шпенглеру на https://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , существует тривиальный способ эскалации в uid 0 с использованием CAP_SYS_CHROOT (возможность использования chroot(2) :

CAP_SYS_CHROOT: generic: от Julien Tinnes / Chris Evans: если у вас есть доступ на запись к той же файловой системе, что и корневой двоичный файл suid, настройте chroot-среду с backdoored libc, а затем выполните жестко привязанный корневой двоичный код в chroot и получите полный root привилегии через ваш черный ход