LINUX.ORG.RU

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

 , , second chroot


0

1

Если впишем в nginx.conf: user www-data то получим такую картину: Запускается master процесс, биндит 80 порт и создаёт потомков под юзером www-data.

Это в принципе и так всем ясно. Если мы поместим nginx в chroot и запустим стандартно chroot /var/chroot/ /usr/sbin/nginx -c /etc/nginx/nginx.conf то родитель будет иметь root привилегии, а значит при взломе получится сделать second chroot и выбраться из чрута.

И вот мы подбираемся к самому интересному моменту :) Есть ли смысл сделать chroot --userspec=www-data:www-data /var/chroot/ /usr/sbin/nginx -c /etc/nginx/nginx.conf при этом биндить nginx-ом любой порт от 1024: и заворачивать трафик с 80 порта на локальный порт nginx-а DNAT-ом? При этом потомки включая родителя будут под www-data пользователем, а значит second chroot обламывается.


Вы вправе делать что угодно с chroot'ом. Но, общепринятно не рассматривать chroot как средство безопасности. Вобще. Есть SeLinux или Apparmor.

mky ★★★★★
()

Как ты собираешь ломать родителя? Он не обслуживает запросы, а только рождает детей (www-data процессы)

anonymous
()
Ответ на: комментарий от anonymous

Он не обслуживает запросы, а только рождает детей (www-data процессы)

Разве? А как у них получается на 80-ом порту всем вместе висеть? Насколько я знаю, родитель проксирует запросы детям. Кстати, апач (родитель) ни раз ломали из-за этого.

ktulhu666 ☆☆☆
()

Да, имеет. Мало того, об это уже ни раз говорилось. Единственное, есть вероятность, что в момент падения/не запущенного nginx может другая служба (с целью взлома подключающихся юзеров, например) повиснуть на непривилегированном порте, но это маловероятно, если, конечно, у Вас не публичный шелл :).

ktulhu666 ☆☆☆
()

man 7 capabilities CAP_NET_BIND_SERVICE. Хватит уже давать рута тем кто в нем не нуждается

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.