chroot без root привиллегий

> Вот ты хочешь патчить ядро. А почему это лучше чем написать свою
> суидный бинарник делающий то же самое, при этом запрет на запуск
> суидных проги из под этого бинарника сделать через
> grsecurity/selinux/... ?

Я уже писал что таким образом ты НЕ сможешь их вызывать изнутри процесса. Как демоны. Что является весьма полезным. То есть во время фазы инициализации ты делаешь что тебе надо, потом делаешь userchroot() на внутренние директории с данными.

Я думаю что в данном направлении кроется весьма интересная ветка развития API и Линукса в целом. А именно пока все "новое", да и часть старого, API : chroot, capabilites, namespace, ... работают только под рутом. На деле это происходит из того что это API развивается в области сетевых демонов и сервисов. Которые получаеют преимущества от его использования. То есть мы наблюдаем что API в линуксе расширяется постепенно интересными разработками. И это правильно. UNIX реинкарнировался в Линукс, который постепенно становится локомотивом развития не только free OS но и UNIX-like OS в целом.

Паралельно с этим происходит интересная тенденция в приложениях типа броузера по превращению их в ОС. Например Яваскрипт, плагины, флеш, Ява-плагины, AJAX, когда у вас локально в броузере крутится фактически программа. На сколько я понимаю Гугл постепенно движется в этом направлении. И там как раз хотелось бы что бы флеш плагин или отдельный сайт видел только то что ему позволено.

Грубо говоря я хочу чтобы на системном уровне мои сертификаты видел только webmoney.ru., который в текущей ситуации может выделить только броузер.

То есть, грубо говоря, раз броузер(и многое другое) все равно неостановимо становится ОС в ОС , то пусть ОС предоставляет ему интерфейсы что бы не надо было писать свою ОС а воспользоватся системными сервисами. И самое интересное что большинство этих сервисов УЖЕ СУЩЕСТВУЕТ в пространстве "для демонов" и там довольно значительно исследовано/отработано.

По этому мое предложение сделать как можно больше API "только для root" сделать доступными для узер-левел приложений.

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

> Нахачить самому это и есть бредовая идея. В том плане что отдельная
> ветка ядра не нужна. Нахачить самому с целью отправить патчи и
> просить включить их в ванильное ядро --- это другое дело.

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

А тут речь идет о довольно "непонятно кому нужном" патче. По этому без его значительного использования в разных проектах об этом говорить не прихождится. Сам концепт так сказать под вопросом. И его надо исследовать не только в теории но и на практике.

> равильнее заменить поведение обычного chroot(), добавив процессу
> наследуемый при fork()/exec() флаг, запрещающий suid.

Да, я над этим как раз думал. В любом случае если сейчас к процессу можно добавить какой либо несмываемый флаг, то вполе возможно наверное включить эту фичу в стандартное ядро. То есть возможность отключать запуск suid(точнее повышение привеллегий при suid) для любого процесса, может найти путь в стандартное ядро.
А тогда уже остальная часть отдельным suid или патчем chroot будет гораздо проще для поддержки.

Но в любом случае без хорошей необходимости это никто не включит в ядро. по этому отсылка патчей скорее бессмысленна.

Без отдельной ФС такой скрипт дает возможность эскалации привилегий до рута. Нормальный админ такое ставить не будет. Пара примеров:

1. Однопользовательская машинка. Крутятся два демона, оба без юзерского чрута и оба под юзером. Пользователь решает "усилить" безопасность -- ставит один из демонов в юзерский чрут с помощью суидного скрипта. Взломщик ломает того демона, который не в чруте, убивает чрутнутого (а может даже и убивать не обязательно) и повышает свои привилегии до рута.

2. Многопользовательская машина, /var не на отдельной ФС (ты про var ничего не говорил :-). Взломщик ломает один из демонов смотрящих в инет, или mysql, и поскольку эти демоны могут писать в /var, то опять же можно повысить свои привилегии до рута.

Таким образом "мера безопасности" становится наоборот -- дальше можно, пока админа нет, подтереть логи, поставить руткит на основе виртуализации, начать снифать траффик -- короче, жизнь прекрасна :-)

> правильнее заменить поведение обычного chroot(), добавив процессу наследуемый при fork()/exec() флаг, запрещающий suid.

да

> Заодно можно будет делать chroot("/") запрещая тем самым вызов из программы SUID-бинарников.

суперская фича, ради нее одной надо уже сделать такое!

Лехко! virtualbox и в нем linux.