>> Для вас домены маршрутизации - это костыли?
> В современном, жестком и дубовом их виде - да.Дубовом? o_O А мужики-то и не знают. Я-то думал, что когда получается быстрее (пробежаться по таблице роутинга быстрее, чем по правилам фаервола), надёжнее (меньше ручной работы = меньше вероятность ошибки конфигурирования) и проще (каждая задействованная сущность проста доступнее в изучении, чем комплексное решение на фаерволе), то оно лучше, ан вот оно как... :)
Я не спорю, что какие-то ситуации наоборот, кроме как тегированием решить нельзя. Но то, что как минимум ситуации с одноимёнными маршрутами в контексте доменов маршрутизации решаются лучше - отрицать, мягко говоря, странно. Ну да то не мои проблемы, что я буду переубеждать. :)
>>Я уже говорил, что в PF напрямую можно тегировать только его средствами. Это как-то более надёжно, ИМХО, чем позволять приложениям выставлять теги. Что будет, если через взлом одного приложения атакующий получит возможность отправлять трафик от имен доверенного?
> В случае с systemd, выставлением тегов занимается процесс init, работающий от рута.
> Вы полагаете, что в случае исполнения кода в контексте init будет
> существенной проблемой модифицировать правила фаервола?
Гм. systemd использует тегирование пакетов для эмуляции доменов маршрутизации? o_O
Давайте мух отдельно, котлеты отдельно (это я в свете грядущих выборов, ага). Я говорил про ситуацию, когда произвольное приложение (не-рутовое) имеет возможность фактически отправить трафик от имени рутового. Понимаете? Получается, надо всё равно давать возможность фаерволу проверять источник пакета. Что приводит в итоге к, фактически, тегированию силами фаервола.
Кстати, если не секрет, а чего это SO_MARK до сих пор не документирован? Я нашёл было ссылку на багзиллу, датированную ещё 2010-м годом, да вот беда: kernel.org-то до сих пор не реанимирован (полностью)... Может, именно из-за описанных выше причин?
Теперь о systemd и других рутовых процессах. Использование тегов сокета в рутовом приложении ничего не даст для этого приложения с точки зрения безопасности. Но:
По-хорошему, логику работы в таких процессах разделяют: основные действия, в том числе обработку данных, совершает непривилегированный процесс, а привилегированный только выполняет какие-то команды. Более того, если программе не требуется использовать критичные (доступные только в привилегированном режиме) ресурсы, то она может банально сбросить привилегии после их, ресурсов, получения безо всяких форков. В обоих случаях возможные эксплоиты не получают рутовый доступ к системе, а могут лишь пакостить в пределах уязвимого приложения.
То есть всё для того, чтобы не было _необходимости_ (не возможности) использовать именно тегирование, по-хорошему уже должно быть. А если нет, то у вас уже есть проблема с угрозой безопасности. И, возможно, не одна.
>>Так что аналогичная функциональность, повторюсь, вполне доступна.
> Не вполне понимаю. Не могли бы вы привести пример реализации тегирования пакетов,
> связанных с заданным сокетом (порт и PID процесса заранее не известны)?
Первый пришедший в голову пример, статика:
match out on <...> user my_daemon_user tag i_want_special_handling
Более сложный, динамика (для понятности даю командами шелла, в Си суть аналогичная):
echo "match from $my_addr port $my_port user $my_daemon_user to $peer_addr port $peer_port once tag i_want_special_handling" | \
pfctl -a myprog/$PPID -f -
Разумеется, вместо tag может быть и любое другое действие, но коли уж говорим о тегировании, то примеры именно с опцией "tag".
>>То, что потребует больших усилий и аккуратности при реализации на фаерволе, может легко решаться посредством доменов роутинга.
> Костыль обычно всегда проще прямого решения, поэтому костыли столь популярны.
Господи, ну хотите, считайте костылём, жалко, что ли. :)
>>Но практичным этот подход назвать никак нельзя.
> Да, пусть лучше костыль на костыле сидит и костылем погоняет. Не слушайте
> старого идеалиста, он бредит.
Да делайте как хотите. Вы же себе жизнь усложняете, а не мне. :)
