[sisyphus] По поводу /usr/sbin/control и su

[Alexey Morozov]

On Tue, Apr 01, 2003 at 01:02:06AM +0400, Dmitry V. Levin wrote:
> 1. Имело место обновление со старого непод'control'ного su до нового
> под'control'ного. На момент обновления ещё не было установлено правила
> сохранения текущего состояния su, ввиду чего по окончании обновления
> состояния su было выставлено в "restricted".
> 
> 2. Поскольку обновление завершено, осталось запустить control и проверить,
> все ли значения соответствуют ожидаемым. При дальнейших обновлениях su (и
> др.) их нынешние состояния будут сохранены.
Ну, это, в общем, уже более-менее понятно.

> 3. Если кто-нибудь придумает способ решения проблемы обновления в п.1,
> который бы не жертвовал безопасностью системы на момент обновления или по
> окончании обновления, то это стоит обсудить.
Гхм... (Шёпотом, чтоб не убили сразу): добавлять фазу интерактивной
конфигурации в пэкедж-мэнеджер, как в... ой!.. молчу!..

Впрочем, если серьезно, то нынешняя ситуация чревата капитальным DoS'ом,
особенно в условиях удаленного или автоматического пакетного обновления.
Как ее решать? А точно не удастся подобрать каким-либо "автоматическим
способом" конфигурацию control'а, которая бы более-менее соответствовала
настройкам по состоянию до начала обновления? Ведь не секрет, что количество
людей, правящих ПАМовские настройки сравнительно невелико, а людей,
_серьезно_ правящих /etc/pam.d/* - и того меньше. То есть, довольно велики
шансы попасть на дистрибутивную или около того конфигурацию некоторой
службы. Ну, то есть, например, в случае su, я думаю, подавляющее большинство
устроил бы public или wheel, в зависимости от того, была ли включена у них
pam_wheel.so в /etc/pam.d/su до обновления или нет. То есть, понятно, что
не серебряная пуля, но и не то <beep> с машиной, затерянной в какой-нибудь
давно не открывавшейся серверной посреди глухой сибирской тайги (вариант:
аризонской пустыни, южноафриканской саванны).