Запретить remount

Может быть все-таки стоит тебе узнать, что делает команда mount? Со всеми ее опциями, там и перемонтирование есть. Но, т.к., речь же идет сквашфс (сорри за мой француский), то может быть стоит обратить внимание на особенности этой файловой системы.

Может быть все-таки стоит тебе узнать, что делает команда mount? Со всеми ее опциями, там и перемонтирование есть

маунт просто делает сисколл, реальным перемонтированием занимается ядро в fs/super.c

Но, т.к., речь же идет сквашфс

/shared - на ext4

«фактически» это как именно?

Слушай, как разница? Механизм отлажен и работает. Вопрос только о перемонтировании к хакерам ядра, я знаю тут такие когда-то были. Вот их помощь мне реально нужна.

/shared - на ext4

А чё ты людям мозги парил про скваш?

По fs и ядру тебе нужно кастовать tailgunner'a тогда. Но, не факт, что он ответит

А чё ты людям мозги парил про скваш?

Людей понесло куда-то не туда. В сторону замены ядра на чужое и прочую ересь. Я сказал что система на squashfs и замена ядра невозможна. Возможно, я описал это не совсем подробно. Корень на squashfs, /shared - на ext4. Хотя ни то ни другое к изначальной задаче не имеет отношения.

tailgunner

Нехороший ты человек. Редиска ты. Ты же бля говорил, что у тебя ядро на скваше лежит, и что загрузчик «понимает» и «верит» в это.

Нехороший ты человек. Редиска ты. Ты же бля говорил, что у тебя ядро на скваше лежит, и что загрузчик «понимает» и «верит» в это.

Ну так ядро и лежит на скваше, при чём тут /shared? Вся система включая /boot лежит на скваше. /shared монтируется динамически и является ext4 системой с noexec,nosuid,nodev.

Ок, классно. Ну и что тебя удивляет? Что ты не можешь быть королем мира?

Ах ну да, ща придет большой бородатый папа и всех помирит? Ой... сорри блин, мальчики ссоряться Еб......и ек..

хоть бы писк бы какой подал , или пук, а то люди не факт, что подумают

Это же фмлофщвшарфщварфвор, и он смог фвдлафуарйушарйура, и тогда фвадофвадолфватфтдфлва, взял и фвжафжварфжвора, но он фждвалфждлватдлфварыфоврпафлоыврпппфывоар

Я не лажу в VFS. Если тебе нужно разобраться в ее внутренностях, я не тот человек, у которого нужно спрашивать. Если нужно тупо запретить remount - патчи mount(2).

мда, советчик... выше по треду совершенно верно отметили что mount дергает сискол

принимай таблетки что дохтор прописал

выше по треду совершенно верно отметили что mount дергает сискол

Надо же, анонимус не отличает mount(2) от mount(8).

да, не усмотрел... понадеялся на то что ты составляешь осмысленные предложения... а так выходит

ТС - как пропатчить ремаунт в ядре? каст tailgunner. tailgunner - я в vfs нуб, но если что, тупо пропатчи ремаунт (в ядре)

Почти правильно. В VFS я даже не нуб, а еще меньше.

никаких сомнений :)

я так понимаю у ТС телек или медиаприставка. То что сквашфс запилили в бутлоадер - гут. Модули, я так предполагаю, подписанные. Возможно в шареный фолдер монтируется внешний носитель и есть желание не допустить его ремаунт на /bin, например.

ТС, насколько сильно предположения отклоняются от реальности?

А почему вы начали смотреть fs/super.c - do_remount_sb(), а не fs/ namespace.c - do_remount(), путь ведь туда передаётся, там и сравнивайте... Но я так, мимокрокодил, ни разу не кернел хакер.

Чем вариант blacklist не устроил? Можно зашить в ядро. Да, hard code, зато будет работать.

namespace.c скорее всего относится к http://man7.org/linux/man-pages/man7/namespaces.7.html . Более того, его патчить тоже надо, т.к. у него свой ремаунт.

Чем вариант blacklist не устроил? Можно зашить в ядро

Что ты имеешь ввиду?

А что мешает сделать umount, а потом mount с желаемыми параметрами? Алсо, прямой доступ к устройству как запретить руту? Потом есть всякие user space решения для доступа к fs.

Не мешай опу осваивать бюджет на манязащиты.

Ммм... А можно слегка бекграунда? Чтобы понять, какие методы имеет смысл предлагать, а какие нет.

Система на squashfs и ядро нельзя поменять в рантайме.

Я тебя огорчу: mmap на /dev/mem даст тебе полный доступ к памяти. Вывод /proc/kallsyms даст тебе смещения. Остальное исключительно дело техники. Так что проверяй наличие CONFIG_STRICT_DEVMEM :)

как вариант, заменить хакинг ядра на навешивание защиты через selinux|capacitible|hardened

capabilities /fix

Так что проверяй наличие CONFIG_STRICT_DEVMEM

Это как и kexec сделано в первую очередь

Ммм... А можно слегка бекграунда? Чтобы понять, какие методы имеет смысл предлагать, а какие нет.

Предлагай любые, будет интересно обсудить.

Это как и kexec сделано в первую очередь

А, ещё тебе придется как-то запретить загружаемые модули и [kj]probes. Иначе чуваки всё равно смогут присунуть чочо.

Предлагай любые, будет интересно обсудить.

Для начала назови граничные условия. Есть у тебя /shared, ты хочешь запретить её remount или mount/unmount? Просто это две разные плюшки.

В первом случае достаточно вставить нужный if в код обработчика в fs/namespace.c для определенной директории.

Во втором случае это полный треш и расчлененка, потому что тебе нужно обеспечить возможность init-системе делать mount и unmount на старте и остановке. В теории, ты можешь проверять PID процесса, который вызвал сисколл в том же обработчике. Но опять же - тебе нужно защитить ядро от модификаций.

А, ещё тебе придется как-то запретить загружаемые модули

модули разрешены только подписанные

В первом случае достаточно вставить нужный if в код обработчика в fs/namespace.c для определенной директории.

Хотя бы первый вариант. Со вторым я буду разбираться отдельно.

Учти, что в ядро не абсолютный путь приходит. Точнее, он может быть абсолютным, но не обязательно :)

В случае если разговор касается squashfs не стоит забывать что любые union mount fs вообще то взаимозаменяемы. Да и многие остальные фс зачастую тоже поддерживают даже неестественное и неродное монтирование.