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

а если ты после этого бинари плохие запускать сможешь?

> а если ты после этого бинари плохие запускать сможешь?

Какие такие плохие бинари можно запускать после чрута, какие нельзя было бы запустить без него?

chmod u+s $(which chroot) - можно будет и без привилегий. Но потенциальные опасности надо всё-таки выяснить сначала...

> Какие такие плохие бинари можно запускать после чрута, какие нельзя было бы запустить без него?

вопрос не 'какие', вопрос 'как'. включите фантазию :)

// wbr

$ mkdir -p xxx/bin
$ ln /bin/ping xxx/bin/ping
$ ls -l xxx/bin/ping
-rwsr-xr-x 2 root root 35864 Mar 14  2007 xxx/bin/ping
$ ldd xxx/bin/ping
        linux-gate.so.1 =>  (0x00f90000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00cd9000)
        libc.so.6 => /lib/libc.so.6 (0x00110000)
        /lib/ld-linux.so.2 (0x009d7000)
$ mkdir -p xxx/lib
$ cp /lib/libc.so.6 xxx/lib/libc.so.6
$ inject_malicious_code xxx/lib/libc.so.6
$ chroot xxx
$ /bin/ping
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
            [-M mtu discovery hint] [-S sndbuf]
            [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination
-= got root! =-

// wbr

Точно. Подобные грабли есть с LD_LIBRARY_PATH, но это решается тем, что для суидных прог эта переменная игнорируется. С чрутом хуже...

> Нет какого нибудь user level chroot функционала ?
fakechroot, plasticfs
Оба работают по принципу LD_PRELOAD хуков к libc-шным функциям, естественно если скомпилировать бинарник статически ничего не выйдет.

> -= got root! =-

До этого я и сам дошел. Но никто не мешает игнорировать изнутри userchroot suid бинари. То есть запускать но без suid. Как тут уже прокоментили

Тут уже написали про LD_PRELOAD_PATH и подобные переменные. Они же есть !

> Но никто не мешает игнорировать изнутри userchroot suid бинари

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

Или например держать в таком userchroot веб броузер. В результате эксплойты броузера как бы не позволят поиметь файлы в хомяке юзера.

> Но никто не мешает игнорировать изнутри userchroot suid бинари.

Бинари этого не знают (на то и чрут), а кто еще игнорировать будет?

...и ЕМНИП, есть capability для chroot - полный root не нужен.

> ...и ЕМНИП, есть capability для chroot - полный root не нужен.

да, есть такой

asmlinkage long sys_chroot(const char __user * filename)
{
    struct nameidata nd;
    int error;

    error = __user_walk(filename, LOOKUP_FOLLOW | LOOKUP_DIRECTORY | LOOKUP_NOALT, &nd);
    if (error)
        goto out;

    error = vfs_permission(&nd, MAY_EXEC);
    if (error)
        goto dput_and_out;

    error = -EPERM;
    if (!capable(CAP_SYS_CHROOT))
        goto dput_and_out;

    set_fs_root(current->fs, &nd.path);
    set_fs_altroot();
    error = 0;
dput_and_out:
    path_put(&nd.path);
out:
    return error;
}

// wbr

$ mkdir -p xxx/bin
$ ln /bin/ping xxx/bin/ping

При этом директория xxx должна располагаться в том же разделе, где расположен SUID-овский бинарник, ведь хардлинки между разделами не работают. В данном примере найти директорию в корневом разделе, куда юзер имеет право на запись, вряд ли получится (при условии, что /tmp в отдельном разделе, естественно).

> При этом директория xxx должна располагаться в том же разделе, где расположен SUID-овский бинарник, ведь хардлинки между разделами не работают. В данном примере найти директорию в корневом разделе, куда юзер имеет право на запись, вряд ли получится (при условии, что /tmp в отдельном разделе, естественно).

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

// wbr

man capabilities. Возможно, оно даже работает :).

> Бинари этого не знают (на то и чрут), а кто еще игнорировать будет?

Сискол будет. При экзеках в chroot проверять на suid. Соотвественно если suid стоит - игнорировать и юзера не менять.

> ...и ЕМНИП, есть capability для chroot - полный root не нужен.

А capability у пользователя root же только, нет ? То есть можно скинуть привеллегии с root кроме какого то набора. В том числе сделать root обычным пользователем.

Но юзеру vasya нельзя сделать так что бы он мог chroot. Чего то такой фичи я не видел. Я что то не понимаю в capabilites ?

В смысле, если chroot был создан не root, то запретить в нем suid?

А ещё была бага/фича, что с помощью второго chroot можно выйти в исходный корень. Раньше она точно работала, не знаю, убрали ли её в новых ядрах. Тут тоже надо специальную обработку делать, если chroot не от root'а ?

Броузер, конечно, можно держать в таком chroot, но если я допустим захочу отправить файл (например, приаттачить его к письму через web-интерфейс)?

А относительно повышенной безопасности запуска демонов, так уж, ИМХО, лучше политики SeLinux, чем chroot.

P.S. Тему вы здесь создали, чтобы подготовиться к общению с разработчиками ядра?

ну тама еще app armo есть какой-то

или еще что-то

chroot не решение проблемы в этом случаае, вы правы

лучше chroot в пустую папку, drop root privileges и разрешить только то что нужно для работы проги :).

> Но юзеру vasya нельзя сделать так что бы он мог chroot. Чего то такой фичи я не видел. Я что то не понимаю в capabilites ?

capabilites можно привязать к выполняемому файлу.

>> Бинари этого не знают (на то и чрут), а кто еще игнорировать будет?

> Сискол будет. При экзеках в chroot проверять на suid. Соотвественно если suid стоит - игнорировать

Ну да, модифицировать ядро и поломать совместимость непонятно ради чего. Проще воскресить pam_capability или как там его звали.

> Раньше она точно работала, не знаю, убрали ли её в новых ядрах. Тут
> тоже надо специальную обработку делать, если chroot не от root'а ?
> Раньше она точно работала, не знаю, убрали ли её в новых ядрах. Тут
> тоже надо специальную обработку делать, если chroot не от root'а ?

Мне кажется что chroot не от рута вообще будет отдельным систенмным вызовом. А багофичу эту фикксят все кому не лень. Правда не хзнаю пофиксили ли это в стандартном ядре


> Броузер, конечно, можно держать в таком chroot, но если я допустим
> захочу отправить файл (например, приаттачить его к письму через
> web-интерфейс)?

Можно держать специальные сервисы вне чрута. Так как там нужно будет только прочтать файл, сервисы будут очень простыми. Так многие сложные демоны делают. Оставляют программу к которой сохраняют открытый дескриптор.

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

> А относительно повышенной безопасности запуска демонов, так уж, ИМХО,
> лучше политики SeLinux, чем chroot.

Политики SELinux дело очень непростое. Шан вправо - шаг влево и кирдык. Я не говорю что они ненужны, я говорю что они выполняют совсем другую функцию. Это способ админа защитится от глюков/багов/фич в программе. А я думаю над способом юзер-левел программы, без админских прав, ограничивать свои права ради большей безопасности.

Тут жек идея в том что бы прога сама себе настраивала, ограничения при старте например. Как делают демоны сбрасывая capadilites только для юрезлевел программ.

> P.S. Тему вы здесь создали, чтобы подготовиться к общению с
> разработчиками ядра?

Я это и сам могу нахачить. Нужно понять насколько эта идея бредовая и возможно есть идея лучьше, прежде чем начинать что то кодить. собственн предпослыки такие : современный брузер ( а так же многие другие программы) становится операционной системой в себе. Некой весьма сложной и громоздской сущностью. А ядро для поддержки этого, точнее для того чтобы такого бреда было меньше, ничего не делает. Хотя для решения тех же проблем на уровне демонов есть chroot, capabilites, SELinux и еще море всего. По этому там где демон просто делает chroot, сбрасываает capability обычная программа-клиент открыта всем ветрам.

Если вы посмотрите на историю линукса то увидите - в ядро добавляют системные вызовы предназначенные для поддержки тех или иных use case на серверах. То есть расширение API линуксу как системе свойственно. А для use case на уровне прикладных приложений - не демонов, такого пока не происходит. Понятно что совместимость и пр, но в том же режиме как и для демонов это будет ИМХО востребовано и тут. То есть как некий наворот линукса который программа может использовать, а может и нет.

> Ну да, модифицировать ядро и поломать совместимость непонятно ради
> чего. Проще воскресить pam_capability или как там его звали.

Совместимость не ломается - userchroot это отдельный сискол :) А старый chroot работает как и раньше. Единственно что, будет патч к exec на предмет провеки откуда делается вызов из chroot или нет. И все.

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

Чем тебя вариант "обычный sudo+самописанная прога" не устроил? Если тебе в чруте не нужен ни root, ни suid.

> В смысле, если chroot был создан не root, то запретить в нем suid?

Да.

> Чем тебя вариант "обычный sudo+самописанная прога" не устроил? Если
> тебе в чруте не нужен ни root, ни suid.

Ты как себе представляешь такой функционал если нужно например запустить брооузер или там openoffice ? Всех в sudo прописывать ? Явный признак что чего то нехватает.

> capabilites можно привязать к выполняемому файлу.

Не знал и не разу не встречал, хотя с capabilites дело имел не раз. В любом случае под рутом, имхо, да ? Где можно почитать про механизм ?

> Ты как себе представляешь такой функционал если нужно например запустить брооузер или там openoffice ?

А какая разница, что пускать? Проверить, что в выбранном каталоге нет SUID-программ, сделать туда chroot, заменить пользователя и пустить программу.

на уровне fs не реализованы cap-атрибуты. Я думаю, Eshkin_kot путает. В одной из статей на lwn приводился пример как было бы круто если бы можно было сделать что-то типа setfcap +cap_chroot /usr/bin/httpd. Но это не реализовано.

> А какая разница, что пускать? Проверить, что в выбранном каталоге нет
> SUID-программ, сделать туда chroot, заменить пользователя и пустить
> программу.

Нужно ВСЕХ прописать в sudo. Если всех не прописывать, тогда надо делать suid бинарь. В которых всякие дырки находят и находят. И такое решеие не удастся использовать как демоны юзают chroot, изнутри кода.

То есть ты для того чтобы воспользоватся chroot который был разработан для использования из под root предлагаешь всем выдать рутовые права. Ограничениые. Клево. Это опять админское решение.


Кстати раз такая пошла пьянка, предлагаю еще и non-root user capabilies ввезти :) Что бы можно было дропать из программы сетевой доступ, открытие новых файлов итп например. Чтобы возмложности демонов были такие же.

> То есть ты для того чтобы воспользоватся chroot который был разработан для использования из под root предлагаешь всем выдать рутовые права. Ограничениые. Клево. Это опять админское решение.

Конечно. Зато оно переносимое. Никаких новых сисколлов с непроработанной семантикой, только штатные инструменты.

>предлагаю еще и non-root user capabilies ввезти :)

имхо лучше это решать профилем для selinux или apparmor.

> А какая разница, что пускать? Проверить, что в выбранном каталоге нет SUID-программ, сделать туда chroot, заменить пользователя и пустить программу.

Аааа!!! А тут кракер использует race conditions. Запускается *одновременно* такой скрипт и мини-скрипт, хардлинкующий в каталог суид бинарь, и в случае неудачи глушаший оба. Из 1000 запусков получится сценарий: 1. проверено, суидов нет 2. записан суид линк 3. запущен бинарник, который с улыбкой запускает суидный бинарник

Предложение kernel-а мне больше нравится.

> setfcap +cap_chroot /usr/bin/httpd. Но это не реализовано.

Как минимум че-то похожее есть в grsecurity. Вообще оно более обозримо (хотя по сути затыкает дырки) чем SELinux.

> Запускается *одновременно* такой скрипт и мини-скрипт, хардлинкующий в каталог суид бинарь

Блин, ну все же взрослые здесь. Дыра очевидна, затычка для нее - тоже, всё решается админскими методами.

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

Туманно вспоминая что может grsecurity -- там вообще можно задать, какие файлы (по регулярке) прога может открывать и для чего, так что там получается пользовательский chroot вообще не нужен вроде... хотя для рутового chroot-a там куча доп. ограничений автоматом типа нельзя посылать сигналы наружу chroot-a.

> Блин, ну все же взрослые здесь. Дыра очевидна, затычка для нее - тоже, всё решается админскими методами.

Как решается??? Я не вижу способа.

>> Блин, ну все же взрослые здесь. Дыра очевидна, затычка для нее - тоже, всё решается админскими методами.

> Как решается??? Я не вижу способа.

Проверять, что чрут находится на отдельной ФС, на которой вообще нет SUID-файлов. Или (еще проще) чрут находится на ФС, смонтированной с nosuid (можно и nodev, для надежности).

Интересно было бы, есть ли _другие_ дыры.

> Конечно. Зато оно переносимое. Никаких новых сисколлов с

sendfile тоже непереносимый, но тем не менее.

> непроработанной семантикой, только штатные инструменты.

Ты что то имеешь против новых сисколоов ? :) Даже Линус против новых сисколлов ничего не имеет. Конечно их надо оттестировать и внедрить, полезность доказать. Но против расширения API тем что люди будут использовать протестов нет.

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

Вот тебе еще :

>Кстати раз такая пошла пьянка, предлагаю еще и non-root user
> capabilies ввезти :)

> Проверять, что чрут находится на отдельной ФС, на которой вообще нет SUID-файлов. Или (еще проще) чрут находится на ФС, смонтированной с nosuid (можно и nodev, для надежности).

Ну это СОВСЕМ другое, чем проверять отсутвие суид файлов в каталоге, что предлагалось изначально.

А вообще chroot полезно делать на спец. ФС nosuid nodev в любом случае.

> Интересно было бы, есть ли _другие_ дыры.

Мне тоже интересно.

>> Конечно. Зато оно переносимое. Никаких новых сисколлов с

> sendfile тоже непереносимый

sendfile по крайней мере между линуксами переносим. А для твоего userchroot нужно будет патчить ядро.

>> непроработанной семантикой, только штатные инструменты.

>Ты что то имеешь против новых сисколоов ? :)

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

> Даже Линус против новых сисколлов ничего не имеет. Конечно их надо оттестировать и внедрить, полезность доказать.

IIRC, сисколл jail предлагался не раз, и ни разу не был принят. А сейчас развитие пошло по другому пути - контейнеры разных типов (от RCFS до OpenVZ) и namespace'ы (ITT практически обойденные вниманием, а зря).

> Новые сисколы как раз и нужны чтобы не городить огород из сушествующих средств.

Почитай о namespace'ах.

> Ну это СОВСЕМ другое, чем проверять отсутвие суид файлов в каталоге, что предлагалось изначально.

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

> Интересно было бы, есть ли _другие_ дыры.

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

Chroot restrictions

* No attaching shared memory outside of chroot
* No kill outside of chroot
* No ptrace outside of chroot (architecture independent)
* No capget outside of chroot
* No setpgid outside of chroot
* No getpgid outside of chroot
* No getsid outside of chroot
* No sending of signals by fcntl outside of chroot
* No viewing of any process outside of chroot, even if /proc is mounted
* No mounting or remounting
* No pivot_root
* No double chroot
* No fchdir out of chroot
* Enforced chdir("/") upon chroot
* No (f)chmod +s
* No mknod
* No sysctl writes
* No raising of scheduler priority
* No connecting to abstract unix domain sockets outside of chroot
* Removal of harmful privileges via capabilities
* Exec logging within chroot

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

Нет. Нет.

Чрут можно делать в подкаталог /, а можно действительно в раздел.

> Вот че запрещают люди, я не знаю, может из этого можно сделать дыру

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

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

> Чрут можно делать в подкаталог /, а можно действительно в раздел.

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

Чем больше думаю, тем больше кажется, что для безопасного браузинга достаточно прописать драконовские правила в грсекурити для браузера (ну и юзать его под спец юзером), а чрут -- лишний гемор. Правда я не специалист тут совсем :-(

> прикрывают дырки, которые забывчивые прогеры могут сделать, забыв отдать какую-то рутовую привилегию после чрута?

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

> sendfile по крайней мере между линуксами переносим. А для твоего
> userchroot нужно будет патчить ядро.

Это он сейчас переносим. Пока его обкатывали - такого не было. Вообще этот sendfile это типичный такой "ненужный" сисколл. То есть никому кроме разработчиков реально специализированного софта, расчитанного на какието мега уровни транзакций, не нужный.

Собственно проблема нового сисоклла - добится чтобы популярные приложения и популярные задачи его использовали.
Для юзерлевела это сложнее. Я уже думаю над use кейсами :) Например в линуксе для мобильных устройств или для каких нибудь терминалов платежных поможет защитить систему от взлома через броузер.

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

Эээ , пиши тогда про камни ? Напомню proposal был ввести userchroot и usercapabilites :) :) :) Цель - добится для userlevel приложений БЕЗ АДМИНСКИХ ПРАВ возможностей натраивать собственную безопасность, как у демонов. У которых это есть и много чего еще.
А ты не про камни моего предложения пишешь, а про камни твоего :)

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

> OpenVZ

Так же не был принят. Из всей виртуализации вообще только KVM вошел, ни vserver(jail...) , ни XEN , ни OpenVZ(а это вообще ужос - патчаное glibc это нечто.)