On Thu, Mar 14, 2002 at 05:20:21PM +0200, Denis Kulgeyko wrote:
> Есть vtund-2.5. Решил я дописать туда chroot() + setuid()/setgid(). Причина: не 
> хочу оставлять процесс, висящий во внешний мир (а надо именно его юзать и 
> именно в иаком виде) работающим под root'ом.
> Сделал, но есть одна проблема: когда именно лучше делать setuid() ?

Как можно раньше.

>   Вкратце о происходящем - сперва делаю chroot(), конфиг читается уже из 
> нового корня, потом процесс fork()'ается и родитель делает exit() а потомок 
> отцепляетя от терминала и висит демоном. Дальше возможны 2 варианта - или это 
> будет клиент или сервер.
>   Если сервер - то он цепляется на порт и слушает его, ждет вызовов от 
> клиентов. Вариант - сделать setuid() здесь. setgid() я делаю тут и это ничему 
> не мешает.

Не забудьте про setgroups(2) и другие необходимые действия.

>   Клиент идет на соответствующий сервер/порт, обменивается ключами, 
> устанавливает соединение, поднимает сетевой интерфейс и через него уже 
> пускает туннель. setuid()/setgid() делаю здесь.

Почему нельзя раньше?

>   Для сервера можно поставить setuid() после поднятия сетевого интерфейса 
> (там делается еще один fork() - так для каждого клиента), но тогда сервер 
> будет от момента начала слушанья порта до подьема туннеля работать с 
> root'овыми правами.
>   Если сбросить привилегии после "цепляния" к порту - то понадобятся 
> root'овые права на подъем сетевого интерфейса, настройку маршрутов, 
> firewall'а и пр. Можно кинуть в новый "/" xто-то типа sudo/super, но они 
> тянут за собой не так уж и мало всякого барахла и являют собой еще одну 
> лишнюю "дыру" (есть setuid + executable - файлы). Да и выглядит это несколько 
> "кривовато".

setuid-root программы в chroot'е сводят всю пользу от chroot'а на нет.

>   Если же делать setuid() сразу после поднятия сетевого интерфейса - то не 
> хватит прав на опускание этого интерфейса при разрыве соединения (ну .. тут 
> он упадет сам), удаление лишних маршрутов (уйдут сами сразу за интерфейсом), 
> вычистку firewall'а и прочее.

Это почему?
Оставьте программе CAP_NET_BIND_SERVICE и CAP_NET_ADMIN, а остальное
сбросьте.

>   Есть еще вариант, который потянет за собой переделку в структуре всей 
> программы - чтобы настройкой интерфейсов и иже с ним занимался самый главный 
> прародитель-демон (потомки его шевелят по мере надобности), который работает 
> под root'ом, но напрямую сеть не слушает. Наверно так и сделаю, если не 
> придумается более лучший вариант, хотя это весьма прилично мороки.

Вот это уже дело.
Возможно, прародитель и не должен быть полным рутом.

>   Вот я сижу и ломаю голову .. как бы это все нормально сделать ?

Немного побольше деталей, и не в этот список рассылки.

> Может что-то подскажете. Заранее огромное пасиба.

Посмотрите:
http://altlinux.ru/index.php?module=articles&action=show&artid=5
/usr/share/doc/vsftpd-1.0.1/SECURITY/DESIGN

Пишите в список для разработчиков или сразу мне.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.