[Security-team] security-team policy

[Vladimir Lettiev]

Если создавать команду безопасности @security-team (SALT ?), то
необходимо разрешить следующий набор вопросов:

1. Кто участники команды и каковы их роли?
2. Каков объём поддерживаемой пакетной базы?
3. Где происходят исправления?
4. Каков цикл работы над исправлением?
5. Как вести работу с майнтейнерами?
6. Какие ресурсы необходимы команде?

Попробую изложить какие я вижу ответы на эти вопросы:

1. Участниками команды может стать любой желающий из ALT Team.
Основные роли:
 * диспетчер - мониторит и сообщает о новых проблемах
 * исправляющий - собирает обновлённый пакет (новая версия ПО или
прикладывает патч), делает бэкпорт в другие ветки
 * тестер - тестирует исправленный пакет в своей среде (sisyphus, бранч)
 * арбитр - лицо, наделённое правом отклонять или принимать сделанное
исправление, разрешающий спорные ситуации
 Роли могут совмещаться, каждый анонсирует себя на то, чем он _может_
и хочет заниматься. Возможно даже задавать ВЕС для той или иной роли,
чтобы было понятно, на что больше он ориентируется. Например, хочу
тестировать(вес-5) в branch4.0 и исправлять там же (вес-1).
Соответственно далее эти веса (и способности) можно учитывать, когда
будет предлагаться выполнить новое исправление. Кто будет исполнять ту
или иной роль в конкретном случае можно решать методом самовыдвижения
и если кандидатов несколько, то оставить выбор за арбитром.

2. Думаю, что мониторится должна вся пакетная база, но необходимо
разделить её по степени важности: высококритичные для работы системы
приложения и библиотеки, серверное ПО, прикладные приложения
пользователя и второстепенные. Соответственно для пакетов 1-го уровня
фикс делается максимально быстро, а для второстепенных может и не
делаться вовсе (но анонс о проблеме должен быть).

3. Если взять, например, Debian, то они декларируют, что исправления
делаются в стабильных поддерживаемых релизах и в тестовой ветке,
нестабильная же ветка не поддерживается. Нам такой подход,
по-видимому, не подойдёт, исправления должны начинаться с Sisyphus, а
далее по всевозможным веткам делаются бэкпорты.

4. Цикл работы.

4.1 Обнаружение.
Основным источником информации о новых уязвимостях в ПО на данное
время является база Common Vulnerabilities and Exposures
(cve.mitre.org). Т.о. мониторинг изменений в базе CVE даёт информацию
(пусть не на все 100%) о новых проблемах. Есть также официальный
ресурс nvd.nist.gov, где изменения в CVE транслируются в виде
RSS-ленты, что удобно для автоматического мониторинга.
Другие источники (возможно вторичные):
	* www.securityfocus.com (также имеется RSS-лента, которую можно
мониторить ботом)
	* www.securitytracker.com (rss-ленты нет)
	* secunia.com (rss-ленты нет, полно рекламы)
	* xforce.iss.net, www.vupen.com и т.д.
	* SA вендоров linux (redhat, debian, gentoo, ...)
Естественно никакой бот не может обработать информацию о уязвимостях,
он может лишь собрать всю информацию вместе и удобно её представить
для анализа человеком. И человек (диспетчер) должен определить
относится ли новая уязвимость к какому-либо ПО из sisyphus или
актуальных бранчей.

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

4.3 Тестирование.
Надо определить список поддерживаемых веток, и кто из команды будет
ответственен за тестирование исправления на конкретной ветке. Не
секрет, что ни у всех есть рабочие копии какого-либо бранча и
произвести тестирование сам исправивший не может. Если нет
тестировщика для какой-либо ветки, то она считается неподдерживаемой.

4.4 Релиз и анонс.
После успешного тестирования, пакеты отправляются в соответствующие
секции update для бранчей и в Sisyphus. Если с пункта 4.1 вести записи
в специальной базе, то анонс (ALTSA) можно потом сгененрировать на
основе данных, введённых в эту базу. Останется лишь подписать его и
отправить в рассылку, повесить на сайте.

5. Согласно политики NMU для обновлений безопасности устанавливается
окно в 12 часов после обнаружения и записи проблемы в багзилле, а для
критичных пакетов окно может быть вообще равно 0.
Думаю, что нужно максимально использовать помощь майнтейнера, ведь он
наиболее заинтересованное лицо в исправлении. Помощь как в качестве
исправляющего, так и в качестве тестирующего. Конечно, он может не
делать исправление для бранчей, в этом случае ему необходимо об этом
сообщить заранее, чтобы другие могли подготовить исправление для этих
бранчей (также надо будет попросить его сделать передачу пакета для
бранчей на @security-team)

6. Нужны открытые рассылки для команды и для анонсов (они есть), нужна
закрытая конференция в jabber с записью истории, для быстрого
коллективного обсуждения вопросов. Возможно кто-то может предоставлять
сборочницу для какого-либо бранча и/или архитектуры x86/x86_64 для
проверки сборки. Нужно сделать закрытый сайт, где собрать
веб-интерфейс к базе, в которой будет вестись вся информация по
уязвимостям и этапах их исправлений. Что-то на подобии багзиллы, но
заточенное под описанный выше workflow. Прикрутить также открытое API
к базе для извлечения полезной всем информации (прикрутить к тому же
sisyphus.ru).



Предлагаю к обсуждению.

-- 
Vladimir Lettiev aka crux <theCrux на gmail.com>