LINUX.ORG.RU

Влияние системных вызовов файловых i/o на chroot и securelevel

 , , security level


0

1

Прочитал интересную статью про взлом chroot'ов при помощи LKM и заинтересовался фичей переписывания системных вызовов. В моем случае - системных вызовов чтения/записи файлов и листинга каталогов.

Статья, которой начитался: https://www.thc.org/papers/LKM_HACKING.html#A-f

Сначала погуглил о том, не препятствуют ли ныне ядра сей фиче, и пришел к выводу, что только взломам с помощью подобных фич препятствуют, с использованием securelevel'ов - фич безопасности, которые в том числе запрещают грузить модули, переписывать неприкосновенные файлы и т.д.

Возникла идея написать забавы ради LKM-модуль, который бы грузился вне chroot'а, но при работе chroot менял бы привычное представление файловой системы внутри его. Например, объединял бы листинги нескольких папок с небольшим количеством файлов (созданных для эксперимента) в одну, а листинги папок с большим количеством файлов разбивал на несколько и перенаправлял вызовы чтения-записи на эти файлы так, чтобы соответствовали переделанным листингам. Обязательно только внутри chroot'а - по понятным причинам, система же должна функционировать при этом безобразии. А чтобы изнутри chroot'а невозможно было назабавить чего-нибудь лишнего и опасного, то в данном chroot должен обязательно повышаться securelevel.

Два вопроса:

1) как возможно (если возможно вообще) изнутри LKM-модуля при вызове файловых i/o определить, выполняется ли вызов изнутри chroot?

2) как возможно (если вообще возможно, а не обязательно затрагивает всю систему) выставлять securelevel только для chroot?

Обещаю, что опыт сей забавы, в случае если успешно удастся разобраться в этом, ранее или поздно будет мною использован для чего-нибудь стоящего ^_^



Последнее исправление: carthrbc (всего исправлений: 2)

1. Смотреть какой процесс вызывал системный вызов, в структуре каждого процесса есть его корневой каталог.

2. Боюсь что никак, securelevel ведь давно из ядра выкинули.

mky ★★★★★
()
Ответ на: комментарий от true_admin

Конкретно, я про это:

To restrict a container with seccomp, you must specify a profile which is
basically a whitelist of system calls it may execute.

Может, инструмент немного грубоватый, но в данном случае поможет: нужно просто запретить syscall для загрузки модулей.

true_admin ★★★★★
()
Ответ на: комментарий от carthrbc

Ну ещё есть ″capabilities″. Если в системе установить запрет на загрузку модулей CAP_SYS_MODULE через ″/proc/sys/kernel/cap-bound″, то с этого момента и до перезагрузки системы никакие модули нельзя будет загрузить. Только это не серьёзная защита, злоумышленик мог отправить машину в reboot, предварительно прописав загрузку своего модуля в init-скрипт.

В новых ядрах, вроде как, эта самая граница capabilities стала индивидуальной наследуемой для каждого процесса, поэтому породителю chroot'а можно выставить запрет на загрузку модулей, запрет на chroot и ещё много чего.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.