chroot networking

Враждебный в чруте? :/

В любом случае, завести по пользователю на каждый чрут и разрулить всё через iptables.

Решение: echo ALL: ALL > $CHROOT/etc/hosts.deny

Чтобы это сработало, приложение должно использовать tcp_wrappers. Если же чужой код решит самостоятельно принять входящее соединение, /etc/hosts.deny не спасёт.

Хотелось бы чтобы это не сказывалось на хост системе - то есть хорошо бы обойтись конфигом внутри chroot.

Точно.

ЛАдно - это не так важно все равно вхот будет закрыт файрволом. Вот выход этого кода меня беспокоит.

Хотелось бы чтобы это не сказывалось на хост системе

И пускать враждебный код? Так не выйдет. Что-нибудь понадобится - SMACK, SELinux, контейнеры или, как вариант для бедных - чрут с отдельным юзером.

К слову, «chroot is not and never has been a security tool».

А если использовать какую-нибудь простейшую виртуализацию типа LXC? Или слишком много геморроя? с другой стороны, там вообще можно оставить приложению только loopback.

Мне надо чтобы оно ходило внаружу - но на список разрешенных хостов только. Если чего придется делать с помощью iptables, просто думал может есть способ тупого решения внутри chroot - гибкость тут не нужна это для скриптового выполнения команды в чруте с подготовкой скриптом этого чрута - то есть суть «три имени/ip разрешить всю остальную сетевую активность прикрыть».

Внутри LXC тоже придется игратся iptables - то есть пока наверное излишне. Ладно пока chroot+iptables.

как вариант для бедных - чрут с отдельным юзером.

Пока план такой. Что страшного может сделать код запущенный в чруте не под рутом кроме как стать сетевым ботом?

То есть если он снесет там все что можно в chroot - не прблема.

Что страшного может сделать код запущенный в чруте не под рутом

При условии корректного входа в чрут и отсуствия уязвимостей в ядре - ничего.

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

Как войти в чрут некорректно?

Например, забыть сделать chdir() в будущий корень перед выполнением chroot().

Или оставить открытый дескриптор каталога — тогда приложение может выйти из клетки при помощи fchdir().

Полезная ссылка: http://www.bpfh.net/simes/computing/chroot-break.html

Спасибо.

Внутри LXC тоже придется игратся iptables

А в чем проблема то?

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

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

Так если все равно играться - можно и с чрутом точно так же - LXC оверкил.

Как по мне с контейнерами намного «играться» чем с chroot*ом.
Есть конечно schroot/dchroot, но на практике их администрировать оказалось в разы сложнее.

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

Есть конечно schroot/dchroot, но на практике их администрировать оказалось в разы сложнее.

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