Почему CAP _CHROOT эквивалентен root?
Ответ может быть как простым, как «Да будет так», так и очень сложным. В моей истории было две аварии МБР, обе из-за того, что "рука была быстрее головы". Есть и другие способы «удалить» раздел в таблице MBR. С помощью программы cli, программы с графическим интерфейсом, манипулирующей первыми 512 байтами диска. В MBR есть место для 4 записей, представляющих 4 основных раздела. Но программы с графическим интерфейсом молча используют расширенную MBR, что может усложнить расследование восстановления. В принципе, вы можете преследовать две цели::-восстановить исходную MBR, -сохранить исходное содержимое раздела. Вы можете использовать базовые инструменты Linux или искать сложные программы с графическим интерфейсом. Если у вас достаточно свободного места на диске, рекомендуется сначала сделать битовую -копию (образа диска ), не трогая исходный диск. Программа R -Studio дает очень хорошие результаты, но я не уверен в лицензии. Если вы знаете тип исходной файловой системы раздела (NTFS, ext3 ), вы можете выполнить поиск по начальной сигнатуре. Любая информация, которую вы помните, об исходных размерах и порядке потерянных разделов может быть полезна для уменьшения пространства, необходимого для сканирования. Ну, например. если вы помните было два раздела первый 20гб, второй 200гб, то можно судить что начало первого может быть рядом с началом диска а начало второго можно найти между секторами 39062500 44040192. Предположим вы ищете NTFS, вы можете искать подпись с помощью команды:
$ hd disk_image.dd -s20000000000 -n2548578304
Выполняя такую команду на исходном диске, вы должны получить привилегии суперпользователя.
Если вы успешно нашли начало разделов, кажется, что проще сохранить обнаруженные разделы, а затем создать новую MBR, в которой вы зарезервируете достаточно места для своих разделов, а затем скопировать сохраненные разделы обратно в новые места.Вы также можете попробовать пересчитать байты в сектора и попробовать перенастроить таблицу MBR с помощью какого-нибудь стандартного инструмента (fdisk, sfdisk, parted), но результат может не оправдать ваших ожиданий. Если вы предоставите более подробную информацию, у нас может быть больше шансов помочь вам. А именно :какова емкость диска, исходные размеры разделов (даже примерно ), способ удаления разделов, ОС, которую вы используете для восстановления MBR и т. д. Если вам нужно найти и сохранить только некоторые файлы, вы можете использовать специальные инструменты, такие как sleuthkit.
Это не необходимо , это один из способов сделать это.
Изменяя корневой каталог, вы делаете недействительными предположения, которые могут делать компоненты системы.
/bin/suработает в предположении, что пользовательская база данных находится в /etc/passwd/ /etc/shadow, чтоlibc(или любая библиотека, с которой она связана ), находится в некотором фиксированном месте в /lib, которое не может изменить ни один обычный пользователь..
Если вы можете создать другой макет файловой системы, в котором та же самая команда /bin/suможет быть запущена, но с другим /etc/passwdили другим libc, которые вы можете изменить по своему желанию, тогда вы можете делать что угодно (поскольку suиспользует или может использовать (, возможно косвенно)/etc/passwdдля аутентификации пользователя, и запускает код в libc ).
При таком подходе иметь CAP_CHROOT— не единственное, что вам нужно. Вам также необходим доступ на запись к каталогу в файловой системе (, так как жесткие ссылки могут быть выполнены только внутри заданной файловой системы ), которая имеет хотя бы один динамически связанный корневой исполняемый файл setuid -.
Нередки системы, в которых системные разделы не имеют пользовательской -области для записи (или даже предназначены только для чтения -). Также распространены файловые системы с пользовательскими -доступными для записи областями, смонтированными с флагом nosuid. Многие системы также запрещают жестко связывать файлы, которыми вы не владеете (см., например, fs.protected_hardlinkssysctl в Linux 3.6+ ).
Но вам не нужно жестко связывать исполняемый файл setuid внутри вашей chroot-тюрьмы. Вы также можете сделать:
chdir("/");
chroot("/tmp/myjail");
execl("bin/su", "su", 0);
так как даже если корень процесса изменен на chroot, текущий рабочий каталог будет по-прежнему доступен после этого, даже если этот каталог /и bin/su, разрешенные оттуда, не внутри . ] Тюрьма. И /bin/suпо-прежнему будет искать ld.so, /etc/passwdили libc внутри вашей тюрьмы, поскольку доступ к ним осуществляется по абсолютным путям, то есть относительно измененного корневого каталога . Если оставить текущий рабочий каталог или любой файловый дескриптор открытым для файла за пределами тюрьмы, вы получите выход из тюрьмы.