From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 20 Jan 2005 11:23:55 +0300 From: Stanislav Ievlev To: ALT Devel discussion list Subject: Re: [devel] P: security volunteam Message-ID: <20050120082355.GD20760@basalt.office.altlinux.org> References: <20050118170339.GS13111@pyro.hopawar.private.net> <20050119135849.1a91449d@pokemon.msk.menatepspb.com> <20050119111038.GX27042@osdn.org.ua> <200501191651.03341.asy@altlinux.ru> <20050119160102.7f6ca2d7@pokemon.msk.menatepspb.com> <20050119155824.GK27042@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050119155824.GK27042@osdn.org.ua> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 08:23:55 -0000 Archived-At: List-Archive: List-Post: On Wed, Jan 19, 2005 at 05:58:24PM +0200, Michael Shigorin wrote: > On Wed, Jan 19, 2005 at 04:01:02PM +0300, vserge wrote: > > Уважаемые коллеги: > > 1) Надо ли нам определить Security policy > > 2) Надо ли расширить Security Team > > 3) Как должна работать Security Team и что будет входить в ее > > обязанности? > > По предварительному обсуждению конца прошлого года могу > предложить такое. > > Желающие поднимают руку и собираются в security volunteers team, > которая координируется security team и по возможности > обеспечивает по возможности оперативный выпуск рекомендаций по > обновлению для (хотя бы) последнего стабильного выпуска. > > Что ожидается от участников -- заинтересованность в результате. > Поэтому, как правило, это системные администраторы, использующие > эти пакеты и системы в боевых условиях. > > Что ожидается от sec team (в лице Димы) -- одобрение кандидатов в > такую команду (скорее номинальное -- с учётом ограничения > выборкой из участников ALT Linux Team?), маршрутизация информации > об уязвимостях (конкретному майнтейнеру или всей команде); > возможно, отслеживание статуса проблем (если на это не найдётся > желающего побыть таким project manager). Тут есть два "но" (но не "нет" ;) ) 1. Одобрение не может быть "номинальным" ибо маршрутизация информации об уязвимостях может идти только к достаточно компетентным и доверенным лицам. Зачастую эта информация носит строго конфиденциальных характер. Соответственно должны быть сформулированы определённые требования к желающим. В частности, это не должны быть недавно подключившиеся к проекту люди. Надеюсь Дима сможет хотя бы примерно сформулировать эти требования. 2. С volunteers ничего нельзя требовать: как своевременного выпуска обновлений так и соблюдения режима неразглашения информации. В связи с этим мне кажется струтура security team должна быть достаточно сложной и иерархической. Должно быть чётко определено взаимодействие между мантейнерами и тем кто выпускает обновления (чтобы не было потом каких-либо взаимных претензий и лишних ссор), а также мера ответственности. Должно быть ясно к кому пользователи предъявляют претензии в случае некорректно собранного обновления. Например, большая часть уязвимостей носит публичный характер и работа по исправлению чисто механическая. Но есть категория пакетов, исправления к которым готовятся достаточно долго и непублично. Для начала, в качестве эксперимента security volunteers team, может заняться выпуском давно пропущенных обновлений, а также обновлениями по пакетам официально не поддерживаемым. Думаю, что мы сможем составить такой список пакетов. Дима, что скажешь? -- Стас.