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

>Трюк с ln не пройдет с нормально поделенным диском (/, /usr, /tmp, /home - на разных ФС). Другие трюки - может быть.

Пройдет!

$ ls -l /bin/mount
-rwsr-xr-x 1 root root 77088 2007-12-22 16:47 /bin/mount

>>Трюк с ln не пройдет с нормально поделенным диском (/, /usr, /tmp, /home - на разных ФС). Другие трюки - может быть.

> Пройдет!

Как?

> OpenVZ(а это вообще ужос - патчаное glibc это нечто.)

Правда? Мне знакомый его хвалил. Хочу узнать недостатки!!!

> Как?

Очевидно -- моунт суидна, ее можно использовать вместо пинга для хардлинка в примере клалафуды, совмещенном с моими гонками.

ой... пинг тоже суидна, и главное -- su суидна, и все они в /bin/

> Это ровно то же. Или у тебя /, /usr и /home на одной ФС?

А у меня например иногда да. И дефолтовые инсталляции часто так ставят.
Понимаешь, твое решение так же требует что бы админ подсуетился. И добавит кучу мусора в конфиги. Либо лишний suid.

Тут идея в том что бы как для демонов предоставить новый API ПРИЛОЖЕНИЮ а не АДМИНУ. Разный подход. Который, напомню, используеися в демонах уже много лет.

> Очевидно -- моунт суидна, ее можно использовать вместо пинга для хардлинка в примере клалафуды, совмещенном с моими гонками.

Ничего не понял. У тебя нет прав записи в /, ка ты линк создашь?

> Тут идея в том что бы как для демонов предоставить новый API ПРИЛОЖЕНИЮ а не АДМИНУ.

Ну да, и вероятность ошибки растет пропорционально числу приложений. Не зря нормальная безопасность идет путем конфигурирования именно системы, а не приложений. Приложения пусть заботятся о том, чтобы в них дыр не было.

> напомню, используеися в демонах уже много лет.

Ну так эти демоны небось старше даже SELinux (кстати, имена демонов - в студию).

> Правда? Мне знакомый его хвалил. Хочу узнать недостатки!!!

OpenVZ это то что хвалят знакомые и ньюфаги. А я юзаю vserver который вызвал этот бум виртуализации еще в прошлом веке :p .

OpenVZ переписывает glibc чтобы перенаправлять себе все сисколлы. На уровне ядра патчи ко всем сисколлам насколько я понимаю не понравились вообще никому :p

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

> Ну так эти демоны небось старше даже SELinux (кстати, имена демонов -
> в студию).

Все вменяемые сетевые демоны. Навскидку помню только sshd, bind, apache,ftpd(почти все). Но возьми почти любой другой и посмотри в трейсах - увидишь дропанье привиллегий "я гарантирую это" :)

> дропанье привиллегий

Ну это понятно, я интересуюсь насчет заключения демоном самого себя в чрут.

> Не зря нормальная безопасность идет путем конфигурирования именно
> системы, а не приложений.

А это от того что отчаялись исправить приложения :p пришлось править систему.

> Приложения пусть заботятся о том, чтобы в
> них дыр не было.

Это оно конечно. Но при наличии хорошего API для самообороны они могут его использовать. :p

Вообще считаю что под не рутовый контроль нужно отдать полно функций. Вплоть до iptables на "свои" порты. И удалять их при выходе приложения of couse

> И вообще, сейчас мне нужна вся эта виртуализация

Я лично не вижу, где теба нужна виртуализация. Изоляция - да, но не виртуализация.

> Ну это понятно, я интересуюсь насчет заключения демоном самого себя в
> чрут.

Точно помню про sshd и большинство ftpd демонов. Про апачь не помню, но подозреваю что тоже может.

>> Не зря нормальная безопасность идет путем конфигурирования именно системы, а не приложений.

>А это от того что отчаялись исправить приложения :p пришлось править систему.

Нет. Это от того, что единственный разумный путь (он же - описанный в стандартах, IIRC) - это сосредоточение всех проверок безопасности в одном месте.

> Я лично не вижу, где теба нужна виртуализация. Изоляция - да, но не
> виртуализация.

Это я не про текущий пропозал а вообще. Человек же вообще про openvz спросил - я вообще и ответил что начинаю эти виртуализации немного ненавидеть.

> Нет. Это от того, что единственный разумный путь (он же - описанный в
> стандартах, IIRC) - это сосредоточение всех проверок безопасности в
> одном месте.

Ты путаешь уровень приложения и уровень админа. То что ftp сбрасывает capabilites не нужно сосредотачивать в одном месте. Это только добавит в это место лишнего текста. А лишний текст - источник ошибок.

А вот настройки которые админ настраиваеьт по безопасности, всякие спецсредства, как раз нужно в одном месте.

> Ничего не понял. У тебя нет прав записи в /, ка ты линк создашь?

1. /home/user/bla-bla-bla/ для чрута плохо, т.к. хомяк часто noexec

2. Для запуска браузера в /chrooted/username/ тебе придется дать username-у права на запись в этот каталог (браузеры пишут в свой конфиг, а лежать он будет там!), и если это действительно "каталог" как ты писал, а не отдельная ФС, то туда можно сделать хардлинк /bin/su /bin/ping /bin/mount по выбору.

( исходя из твоих пожеланий чтобы я выражался точнее -- вот тебе пример, когда надо было тебе выразиться точнее; но на самом деле в дискуссии, похожей на мозговой штурм, ошибки в терминологии просто неизбежны, так что с моей стороны лучше было бы твою неточность вежливо не заметить)

> Ты путаешь уровень приложения и уровень админа.

Нет.

> То что ftp сбрасывает capabilites не нужно сосредотачивать в одном месте

ftpd сбрасывает рута, а не capabilties.

> ftpd сбрасывает рута, а не capabilties.

Он сбрасывает capabilties ровно на столько что бы потом переключится на другого пользователя и все. А когда переключается сбрасывает и root.

> Для запуска браузера в /chrooted/username/ тебе придется дать username-у права на запись в этот каталог (браузеры пишут в свой конфиг, а лежать он будет там!), и если это действительно "каталог" как ты писал

Есть куча способов облажаться, с этим никто не спорит. Но твой - какой-то слишком неестественный. Если на машине есть пользователи, которым нельзя доверять, то админ должен как бы проявлять осторожность. Если дать этим неблагонадежным пользователям возможность записывать в /, они ведь и DoS могут устроить (решается квотами, да. Но при настройке квот неизбежно всплывет вопрос об отдельной ФС).

А если пользователям можно доверять, то и вопроса нет - проверка поддерева на отсуствие SUID-бинарей достаточна.

> с моей стороны лучше было бы твою неточность вежливо не заметить

Это не было неточностью. Я рассчитывал на том, что до столба никто доколебываться не станет.

>> ftpd сбрасывает рута, а не capabilties.

> Он сбрасывает capabilties ровно на столько что бы потом переключится на другого пользователя

В традиционном Unix нет capabilities. Ты утверждаешь, что ftpd пользуется каким-то Linux-специфичным вызовом?

> В традиционном Unix нет capabilities. Ты утверждаешь, что ftpd
> пользуется каким-то Linux-специфичным вызовом?

Я по привычке называю ftpd все эти wu.ftpd и vsftpd . Для переносимости они юзают capabilities при компиляции под линукс, через ifdef, и не юзают их на других юниксах.

> Есть куча способов облажаться, с этим никто не спорит. Но твой - какой-то слишком неестественный.

В таком случае (каталог, а не раздел), поломав чрутнуый браузер и получив локальные права пользователя, при должной сноворвке можно их повысить до рута.

Прочитал про namespaces, понял что давно юзаю их через vserver утилиты, и еще раньше через --bind о чем читал в мане. Но об этом забыл. Много думал :)

Кстати идея очень хорошая. Но как я понимаю namespaces это тоже из под рута. Даешь юзерлевел namespaces !!! :)

> поломав чрутнуый браузер и получив локальные права пользователя, при
> должной сноворвке можно их повысить до рута

Смотрит на карточку "Повысить до рута - плохо". Это плохо, да ? (С) дильберт

Я всегда говорил что лишний рут это плохо и нужно делать как можно больше безрутовых сисколов и возможностей. Пусть и ограниченых

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

Так что по-моему чрут слишком сложен становится.

ЕМНИП (но помню плохо!) Х-вый протокол позволяет много чего сделать, чуть ли не кейлогер. Так что браузер все равно придется запускать под другим юзером, да еще и в двойной ФС для чрута...

По-моему, чрут явно не годится.

>> поломав чрутнуый браузер и получив локальные права пользователя, при >> должной сноворвке можно их повысить до рута

Ты при цитировании опустил ключевой момент -- именно в каталоге, в отдельной ФС я не знаю дыр.

Я (при всем своем дилетантизме) для себя сделал такой вывод:

1. Юзерский чрут не нужет

2. Вместо него нужен пакет hardened-browser, в котором идет хардлинк на стандартный браузер и куча правил для grsecurity/apparmor/selinux/чего-то еще, все правила от рута, которые запрещают укрепленному браузеру почти все.

3. Никаких суидных бинарей не добавляется, разделов с ФС не делается, чрутнутых окружений при апгрейде системы не поддерживается.

И в чем я не прав?

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

user namespaces в массы ! :) Шютка с долей истины.

Для тех же демонов делается не так. Можно сначала mmap либы, а потом userchroot и падение привиллегий. Либы остаются за chrootом

Если есть user capabilites то по аналогу с демонами сначала exec где стандартные либы, потом дроп всего чего нужно(либы остаются заюзанными. но повторно открыть их нельзя) и работа только с данными, запрет на запись для внутренних конфигов и пр.

> И в чем я не прав?

Ну на самом деле и SElinux с Apparmor тоже не нужны. Ходят же в винде безо всякого selinux , чистят потом от вирусов и все. :)

Нужность-ненужность понятие растяжимое.

Все это по-моему сложнее простых правил "читать только это, писать только сюда, все остальное (запускать, сигналы,...) нельзя"

> Нужность-ненужность понятие растяжимое.

ЕМНИП (могу и ошибиться) пользовательский чрут -- это ровно 1 (одно) правило из grsecurity.

> 2. Вместо него нужен пакет hardened-browser, в котором идет хардлинк
> на стандартный браузер и куча правил для
> grsecurity/apparmor/selinux/чего-то еще, все правила от рута, которые
> запрещают укрепленному браузеру почти все.

> 3. Никаких суидных бинарей не добавляется, разделов с ФС не делается,
> чрутнутых окружений при апгрейде системы не поддерживается.

У вас у обоих админский подход. То есть подход человека у которого всегда есть рут. И у которого всегда ответ юзеру "я админ а ты дурак, мои настройки для твоего блага"

Если это API внедрить, то безопасностью приложения сможет заниматся разработчики приложения. И нужную структуру каталогов для chroot они будут поддерживать при инсталляции. То есть целую кучу аспектов безопасности можно будет переложить на разработчиков - дать им инструменты что бы они СРАЗУ ДЕЛАЛИ безопасные приложения. И не обязательно все будут такие приложения. Если этот API будет разумен, то даже если го будут использовать не все сетевые приложения работающие от пользователя, то и фиг с ним. Те что будут будут гораздо более надежными.

И никто не мешает разнести этот API по другим юниксам, хотя бы свободнораспостраняемым.

в том смысле, семантику пользовательского чрута можно задать с помощью ровно одно правила -- (не помню точно синтаксис)

DenyReadWriteExecuteAppendOutsideOf program=/usr/bin/hardened-browser dir=/home/*/hardened-browser/

не так?

> ЕМНИП (могу и ошибиться) пользовательский чрут -- это ровно 1 (одно)
> правило из grsecurity

И которое не проверяет на suidность внутри, да ?

И кстати grsecurity похоже в переспективе будет вытеснен SElinux

Кстати я бы даже так сказал - дайте мне(процессу не root) настраивать свой grsecurity/SELinux. Естественно соблюдая простые правила - не мочь повышать привеллегии выше тех что не дадены, а накладывать толькол ограничения.

> То есть целую кучу аспектов безопасности можно будет переложить на разработчиков - дать им инструменты

Такой инструмент есть -- сборщик deb/rpm пакетов.

И организационно *правильно*, чтобы админ был начальник, а сборщики делали пакеты.

> И которое не проверяет на suidность внутри, да ?

В данном случае это не нужно, так как *корень не меняется*.

> И кстати grsecurity похоже в переспективе будет вытеснен SElinux

Оно по-моему почти умерло, даже доков нет и вики (только пример конфига, и даже не на сайте).

> Кстати я бы даже так сказал - дайте мне(процессу не root) настраивать свой grsecurity/SELinux.

Пиши правила в пакет, админ посмотрит и поставит.

> я админ а ты дурак, мои настройки для твоего блага

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

да и вообще я хочу знать заранее, что ты там делаешь, а не после того, как ты поковырялся в моей системе

З.Ы. просьба не обижаться, я больше прогер, чем админ

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

Ну тогда и проверял все что программа делает под своими правамии доступа. Чего же это ты не следишь орлиным взором за 200 приложениями в твоей системе :) ?

Ищо раз для непонятливых, я предлагаю что бы приложение могло себя САМО ОРГАНИЧИВАТЬ. То есть делать меньще, чем то что ты и так не замечаешь :)
И решения о самоограничания будет применять программер. А в системе будет API которые будет так устроено что бы НЕ ДАТЬ в ЛЮБОМ СЛУЧАЕ, проге выйти на уровень того что ей админ запрещает разрешает.

Ты прочитал что я тебе написал насчет редактирования правил ВНУТРИ того что уже ей разрешили, а ?

Кстати -- если из под юзерского чрута можно сделать *повторный* юзерский чрут -- то по-моему всплывают все те же самые проблемы с хардлинками!

> Ты прочитал что я тебе написал насчет редактирования правил ВНУТРИ того что уже ей разрешили, а ?

Напиши

1. (если он уже не написан и если это возможно, ведь это м.б. и НЕ возможно!) верификатор правил для СЕЛинукс, который проверяет правила на то, что они дополнительно запрещают

2. демона, которому можно скармливать свои правила, а он их будет верифицировать и добавлять от рута

ИМХО это куда лучше кучи левого кода в ядре

Ну и такой же верификтор для правил iptables

> ну тогда и проверял все что программа делает под своими правамии доступа. Чего же это ты не следишь орлиным взором за 200 приложениями в твоей системе :) ?

Их (демонов) обычно < 20,

а по делу -- мне бы хотелось, чтобы при отработке скрпитов из установочного пакета (именно при, а не после!) фиксировались все изменения в системе (какие файлы отредактированы)

> 1. (если он уже не написан и если это возможно, ведь это м.б. и НЕ
> возможно!) верификатор правил для СЕЛинукс, который проверяет правила
> на то, что они дополнительно запрещают

Ога - вот по этому я думаю над более простыми решениями :) Верификатор SELinux это как и весь SELinux лютый п-ц.

И кстати userlevel chroot с помощью него реализовать будет все равно невозможно.

> Верификатор SELinux это как и весь SELinux лютый п-ц.

Значит надо найти замену (apparmor?), или подмножество СЕЛинукс, в котором аналог чрута будет 3 строчками.

Я для себя еще раз освежил позицию Ъ админа, и понял, что надо изучить что-то на замену грсекурити. А дальше доказывать свою, в данном случае админскую, позицию мне влом, сорри.

Но разговор был интересный, да.

не, я все-таки тебя спрошу.

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

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

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

ИМХО, отдельный syscall типа userchroot() не нужен, правильнее заменить поведение обычного chroot(), добавив процессу наследуемый при fork()/exec() флаг, запрещающий suid. Заодно можно будет делать chroot("/") запрещая тем самым вызов из программы SUID-бинарников.

Патчи для user-capabilites были, но не прижились. Но, ИМХО, capabilites это средство ограничит процесс, то есть процесс убирает с себя лишние права, а давать пользовательском (не-root) процессу с помощью CAP_SYS_CHROOT на файл право делать chroot без запрета на выполнение SUID-бинарников не надо.

>> Есть куча способов облажаться, с этим никто не спорит. Но твой - какой-то слишком неестественный.

> В таком случае (каталог, а не раздел), поломав чрутнуый браузер и получив локальные права пользователя, при должной сноворвке можно их повысить до рута.

Нет. Или покажи, как. Обычный пользователь не может выбраться из аккуратно созданного чрута (а команда chroot создает его аккуратно), стать рутом бе взлома SUID-бинаря нельзя. Таким образом, при отсуствии злонамеренных пользователей мой способ создания чрута (даже без уточнений об отдельной ФС) безопасен.