Re: [Comm] Re: Безопасность

[Dmitry Derjavin <dd@farpost.com>]

On Mon, Jan 03 2005 at 06:47, "Dmitry V. Levin" <ldv@altlinux.org> wrote:

>> > По сути ничего не изменилось.  Просто объём поддерживаемой базы
>> > вырос в несколько раз, преимущественно за счёт потенциально более
>> > уязвимого кода, соответственно, объём выпускаемых обновлений тоже
>> > вырос.
>> 
>> Ну и что? По-моему, это совершенно типичная ситуация, которая решается
>> на уровне менеджмента.
>
> Или не решается. :)

Это тоже типичная ситуация. :)

>> А вовсе не на уровне аудита кода или подготовки обновлений.
>
> И на этом уровне тоже.

Нет, не на этом. Тут что-то из серии мух и котлет: сначала, видимо,
имеет смысл сформулировать проблему, максимально абстрагировавшись от
деталей производственного процесса. "Есть некое производство, объём
которого постоянно растёт, в связи с чем имеющихся ресурсов становится
недостаточно для поддержания качества на прежнем уровне" -- как-то
так. И решать эту проблему, по-моему, нужно как раз в подобной
формулировке, и уже менеджерам производственного процесса, а не
программистам, которые, я подозреваю, пытаются её сейчас решить.

>> > Пришлось чем-то пожертвовать.  Лучше уж сократить выпуск
>> > анонсов, чем выпуск обновлений, хотя и он тоже неизбежно
>> > сокращается.
>> 
>> Не лучше, а гораздо хуже -- уверяю вас. Особенно в связи с тем, что
>> сокращается выпуск обновлений. Думаю, что именно с точки зрения
>> безопасности гораздо правильнее в такой ситуации сосредоточиться на
>> подготовке анонсов. В этом случае те же админы сэкономят кучу
>> времени, если будут точно знать, уязвима конкретная сборка или нет.
>
> Я не умею сочинять анонсы к незафиксенным уязвимостям.  И не хочу
> уметь.

Имелось в виду примерно следующее:

http://lists.altlinux.ru/pipermail/security-announce/2001-March/000001.html
http://lists.altlinux.ru/pipermail/security-announce/2003-September/000187.html

На этой кожуре от банана отпечатки ваших зубов, Дмитрий. ;)

>> А обновление можно будет подготовить средствами сообщества. Как,
>> например, и получилось недавно во время совершенно безобразного, на
>> мой взгляд, инцидента с php.
>
> По-моему, с php давно всё плохо.  Могу назвать ещё несколько таких
> пакетов, которые со временем уходят (или не уходят, хоть и должны) в
> contrib из-за неподдерживаемости.  Вы, думаю, тоже.

Что "тоже" -- в contrib? :)

А если серьёзно -- по-моему, php это один из важнейших элементов
современного web-сервера. И если дистрибутив позиционируется как
серверный, то в contrib такому пакету никак нельзя. И не важно при
этом, "хорошо" с ним или "плохо". Нужно сделать, чтобы стало хорошо.

> Что касается подготовки обновлений средствами сообщества, то я готов
> это направление поддерживать, как наиболее естественное в
> сложившейся ситуации.

Замечательная новость. Предлагаю начать с официального объявления, в
котором бы однозначно оговаривалась сфера ответственности Security
Team.

>> Давайте пока не будем. Во всяком случае, пока Security Team таким
>> странным образом расставляет приоритеты..
>
> Я убеждён, что исправление важнее анонса.  Сисадмин в состоянии
> проанализировать степень угрозы скорее, чем подготовить исправление.

А ещё он должен быть в состоянии оценить заранее затраты своего
времени и их примерную стоимость.

Представьте себе такую ситуацию: в Bugtraq появляется информация об
уязвимости, при этом Security Team молча готовит обновление. По
"независящим причинам" подготовка затягивается. Но в силу некоторых
особенностей altlinux риск использования именно этой уязвимости на
дистрибутивах altlinux минимален. Админ оценивает (справедливо), что
на то, чтобы убедиться, что риск действительно минимален, ему
потребуется гораздо большее время, чем потенциальному злоумышленнику
на взлом. И готовит обновление самостоятельно. Через некоторое время
выходит официальное обновление, уже никому не нужное. В результате
потрачено время на подготовку двух бесполезных обновлений. При этом,
чтобы избежать потерь времени, достаточно было бы вовремя опубликовать
маленький анонс.

Таким образом, отсутствие анонсов приводит к гораздо большим затратам
времени, чем отсутствие обновлений.

Достаточно ли это убедительный пример?

-- 
~dd