Ограничение доступа к устройствам на уровне процесов , куда смотреть?

Привет, дорогой алл!

Где-то не то на опеннете, не то на лоре мельком увидел что в ядро добавлена сабжевая возможность. Найти источник сейчас не смог, потому решил обратиться за советом.
Хочется мне реализовать следующий сценарий: есть процесс, запускаемый от рута. Я знаю что ему надо уметь общаться с сетью, писать логи в /dev/log, и т.д. То есть я могу выделить перечень устройств, к которым процесс должен иметь доступ. Но я очень не хочу чтобы он смог читать раздел /dev/sda, и прочие интимные места.

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

Цитата mmonk @ 29.07.08, 09:41

Если есть более простой способ, ткните носом плизз.

Ясное дело есть, запускайте процесс от другого пользователя который "уметь общаться с сетью, писать логи в /dev/log, и т.д.".

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

Сообщение отредактировано: mmonk - 29.07.08, 13:40

в iptables можно писать правила на pid, uid и gid.

Цитата mmonk @ 29.07.08, 09:41

Если есть более простой способ, ткните носом плизз.

chroot

Еще конкретизирую ситуацию. Ограничение направлено на то чтобы в случае взлома сервера атакующий имел минимальные возможности в плане получения доступа к остальным частям системы.
Если я правильно понимаю, никто не помешает внутри чрута создать файл устройства /dev/sda и спокойно в него писать или читать из него. Или примонтировать разделы.
Те же проблемы с iptables. Процесс с правами рута может сбрасывать любые правила. Опять же, iptables не запрещает поставить promisc mode на интерфейсе и слушать пакеты.

Пока все что приходит в голову - user-mode-linux. Там можно задавать доступные устройства, но возникают проблемы с тем чтобы патчить ядро, и с администрированием. Фактически каждый сервис должен жить в своей собственной системе. Проблемно перекинуть файлы между виртуальными осями, и т.д.
А душа просит простого решения в стиле
restrict_process --config=/etc/allowed-devices/daemon-name.conf /usr/sbin/daemon

Сообщение отредактировано: mmonk - 29.07.08, 20:15

Цитата mmonk @ 29.07.08, 13:37

Я исхожу из ситуации когда процессу приходится давать рутовые права.

Опять таки, зачем ему рутовые права, если процесу нужны только ограниченные возможности?

Например, чтобы работать на привелегированном порту. Или детектор сканирования которому нужно ввести интерфейс в promisc mode. Не я пишу программы которые приходится устанавливать. В идеале да, все что требует рутовых привелегий должно их сбрасывать после выполнения необходимых операций. Но в реальности это происходит далеко не всегда. Иногда потому что программу писали не думая о безопасности, иногда потому что нужно периодически повторять операции, требующие привелегий.
В итоге получается что процессу нужны ограниченные РУТОВЫЕ права. В большинстве случаев я знаю что ему нужно, а что нет. Но достаточно простого способа применить ограничения пока не нашел.