Блеск и нищета Systrace

Антон Карпов & Андрей Матвеев

Хакер, номер #070, стр. 070-074-4

% Systrace -a ls /etc

ls: /etc: No such file or directory

Systraced shell

Думаю, ты уже задался вопросом, какая польза end-user'ам от всех этих правил, если они работают только при скармливании программ систрейсу. Не будет же пользователь писать Systrace -a перед выполнением каждой команды. Вот было бы здорово, если бы Systrace был вшит в шелл и его работа была прозрачной для юзера. Что ж, Jose Nazario помог сделать мечту реальностью. Скачиваем stsh с monkey.org/~jose/software/stsh/, компилируем, кладем в /bin/ и создаем класс Systrace, добавив в /etc/login.conf следующее:

# vi /etc/login.conf

Systrace:\

:shell=/bin/stsh:\

:tc=default:

Затем перестраиваем хэшированную базу /etc/login.conf.db:

# cap_mkdb /etc/login.conf

Так мы создадим новый класс пользователей, оболочкой для которых будет выступать systraced shell. Login class - очень удобная BSD-фича, позволяющая гибко управлять пользователями, назначая разным классам разные ограничения, виды аутентификации, переменные окружения и прочее (смотри man 5 login.conf). Затем, если при создании пользователя ты назначишь ему класс Systrace, в качестве шелла у него будет csh/ksh/zsh, но уже systraced.

Сразу отмечу, что эти деяния сопряжены с большими трудностями - тебе нужно будет сочинить политику для каждой программы, начиная с шелла пользователя, иначе работа простого юзера превратится в мучение. В комплекте stsh идет несколько темплейтов, но этого явно мало. У проекта Hairy Eyeball (http://blafasel.org/~floh/he/) правил побольше, но все равно придется доводить его до ума руками. Я знаю только одного хостера, практикующего systraced shell'ы, - это хакерский притон monkey.org. Если когда-нибудь уломаешь их админа заархивировать тебе весь его /etc/systrace/ - стукни мне в мыло, я тоже буду не прочь глянуть ;).

Контроль за повышением привилегий

Помимо простого разрешения и запрещения системных вызовов, Systrace умеет повышать привилегии процессов (privilege elevation). Нет нужды в сотый раз рассказывать, что suid/sgid-биты изменяют привилегии программы, запуская ее от имени другого пользователя (конкретно - ее владельца), и чем чревата уязвимость в suid root-программе (программе, принадлежащей руту и имеющей установленный suid-бит). Простейший пример - это программа /sbin/ping. Чтобы сформировать и отправить ICMP-пакет, проге требуется создать RAW-сокет, а подобное право в UNIX имеет только root. Очень часто - и ping как раз демонстрирует это - права суперпользователя нужны для выполнения всего лишь нескольких вызовов, у ping это socket(AF_INET, SOCK_RAW, IPPROTO_ICMP). Однако chmod +s ставит под угрозу всю программу. Systrace позволяет избавиться от suid/sgid-бита, повышая привилегии программы только на определенные сисколлы. Для этого в правило нужно добавить директиву as root, например: native-socket: sockdom eq "AF_INET" and socktype eq "SOCK_RAW" then permit as root.