On Mon, Oct 02, 2006 at 08:10:09PM +0300, Andrew Kornilov wrote: > Dmitry V. Levin wrote: > > Пардон, что так затянул с ответом :( Сказал, что отвечу через несколько лет, а потом передумал :) > >>>Какой в этом смысл? > >>>Постящий bug report и так может пометить его как security. > >>> > >>Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы > >>не увидит описание проблемы, > > > >Предполагается, что для этой группы ошибок важна конфиденциальность. > > > Для всех пакетов? А зачем? Я понимаю, когда есть серьезная уязвимость и > exploit для неё и это приложение используется повсеместно. Но ведь > ежедневно находят немалое количество не очень серьезных уязвимостей, > которые, однако, исправить нужно в обозримом будущем. Если нет общей > системы для их учета, то приходится их писать на бумажке/в файле. И > читать одному человеку все рассылки по уязвимостям несколько > проблематично. Если уж элементарные баги сам найти не можешь в своем же > и используемом самим же пакете, тогда как другие натыкаются на это > сразу, то с этими уязвимостями ситуация еще хуже. Идея в том, что если вы хотите сохранить конфиденциальность, то выпомещаете bug report в эту группу. Если же вам просто нужно дать понять, что bug report is security sensitive, сделайте его blocker и добавьте [security] в subject. > >>Чтобы видеть, с какими пакетами проблемы. Неработоспособность видна > >>сразу обычно, как быть с безопасностью? > > > >Пойдите на http://cve.mitre.org/cve/ и посмотрите. > > > Там не всё. Вот только что приехала уязвимость на OpenVPN: DoS, System > Access; на mitre.org её нет. Что мне делать? Ждать, когда об этом узнает > майнтейнер, повесить баг, пересобрать самому? Вы же не secoff, зачем вам быть в курсе всего? > >>Если бы был некий список > >>уязвимостей приложения и их статуc в Сизифе, было бы проще узнать, > >>можно ли его использовать в данный момент. Вот кто сходу может ответить, > >>можно ли использовать нашу сборку openvpn? А sshd? А как быть с > >>утилитами типа rkhunter, которые проверяют версию приложения? Он ведь > >>упорно ругается на наш sshd как на уязвимый, хотя это и не так. Кому > >>верить? Как проверить? > > > >Либо я вас не понял, либо вы наивно полагаете, что дырявость пакета так же > >легко проверяется, как и собираемость. > > > Неплохо бы иметь список проблем из разных источников, чтобы не метаться > по всем рассылкам. Да и security hole может быть и не из-за уязвимости > самого приложения, а из-за того, что майнтейнер установил некую опцию > типа RemoteRootAccess=yes. Ну и т.д. Вы не понимаете, что занести указатель на проблему в bugzilla легко, в вот установить факт наличия проблемы нетривиально? > >Хотя есть, конечно, разные категории пакетов. > >Например, есть такая категория пакетов, про которые известно, что они > >дырявые от природы. > > > Но иногда и они нужны, когда больше никто подобную функциональность не > предоставляет. Можно его как-то пометить, мол, вечно уязвимый, но > оставить. Я помню ситуацию с ntop несколько лет назад, когда мне > преложили его поместить в какой-то определенный каталог с "плохими" > приложениями, когда я предложел его в сизифе разместить :) Без комментариев. > >Как вы можете проверить, является ли пакет openssh в Сизифе уязвимым? > >Это зависит от вашей профессиональной подготовки. > > > >Давайте это проверим. Ответьте, по возможности, аргументированно на такой > >вопрос: подвержен ли уязвимости CVE-2006-2607 пакет vixie-cron в Сизифе? > >Как бы вы стали проверять crond на CVE-2006-2607? Вешать багу на пакет? > > > Понятия не имею. Плохо. Очень плохо. > У меня нет перез глазами явного списка всех его уязвимостей. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vixie-cron > И исправлена ли она, я могу (с трудом) определить, почитав > изначально --changelog (и поверим майнтейнеру, который написал там, мол, > исправлено), В данном примере changelog вам не поможет, поскольку ошибка была исправлена примерно за два года до того, как её стали считать уязвимостью и присвоили номер CVE-2006-2607. > могу почитать про уязвимость, посмотреть исправления, > заглянуть в код и с некоей долей вероятности определить, что, видимо, > [не]исправлено. Вот именно. > >>>>bugtraq читают многие, я думаю. > >>>> > >>>Не факт. Этот список рассылки последнее время стал малоинформативным. > >>> > >>Но как быть тогда? Аналога полноценного нет. > > > >Это не так. Есть много списков рассылок, которые вместе взятые дают > >достаточно полную картину того, какие пакеты и на какую тему _принято_ > >исправлять. > > > И все эти списки рассылки должен читать каждый майнтейнер? Я думаю, что > на это не согласятся даже за деньги :-) Нет, майнтейнер должен читать списки рассылки по своим пакетам, тогда он вряд ли пропустит информацию об уязвимости в нём. > >>Но это ведь не повод игнорировать вообще проблемы с безопасностью. > > > >Нет, конечно. Но мне кажется, что ваш взгляд на этот вопрос несколько > >упрощённый. Припоминаю, как несколько лет назад непосредственно перед > >релизом какой-то версии Mandrake была найдена какая-то довольно глупая > >ошибка в их пакете SysVinit, после чего один пользователь написал в список > >рассылки предложение быстренько проверить и устранить оставшиеся дырки. :) > > > >Видите ли, если к безопасности относиться серьёзно, то это сложная > >многослойная задача. > > > Да это все понятно. Не факт, что всем, кому это должно быть понятно, это действительно понятно. > Но сейчас мне вообще непонятно, кто и что проверяет и контролирует. Я всё проверяю и контролирую. :) > И есть ли это вообще. Я могу быть майнтенером мелкой > утилиты, которую мало кто использует, но она есть в базовой системе и > для неё уже два года как local root exploit есть. Что с ней будет? > Видимо, ничего. Это вряд ли. Ваш пакет не может попасть в базовую систему случайно. > >>>>Но ситуацию с security, похоже, никто не отслеживает совершенно. > >>>> > >>>Ну, тут вы сильно заблуждаетесь. :) > >>> > >>Я очень на это надеюсь. Но очень хочется увидеть какие-либо упоминания > >>об этом, а еще лучше результаты. > > > >Я определённо не понимаю, какое упоминание и какой результат вы хотите увидеть. > > > К примеру, оповещение где-либо о том, что исправлены такие-то ошибки и > доступны новые пакеты. Как это было раньше для пакетов из коробочных > дистрибутивов (и есть ли оно сейчас для них?). Все это достаточно не > сложно автоматизировать, если захотеть :) Автоматизировать исправления уязвимостей нельзя. Автоматизировать рассылку уведомлений можно. Видимо, заняться этой автоматизацией некому. > >>>>p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", > >>>>что будет после заморозки? Некие специальные люди будут читать весь > >>>>архив bugtraq и анализировать текущие версии пакетов на предмет > >>>>уязвимостей или это будет выпущено as is? > >>>> > >>>Коллега, вот я бы на вашем месте подумал, что будет в плане задраивания > >>>отверстий в пакетах уже после релиза. > >>> > >>Не совсем понял. То есть, выпустить дистрибутив с уязвимостями можно, > >>главное, чтобы потом кто-то их исправлял? > >> > >Я имею в виду, что исправлять уязвимости в уже выпущенном дистрибутиве > >в течение всего срока его жизни существенно сложнее, чем выпустить > >дистрибутив с заткнутыми опубликованными дырками. > > > Насколько сложно? Сколько нужно людей на fulltime, чтобы исправлять в > среднем, одну уязвимость в день, пересобирать пакет, как-то тестировать > и выкладывать в публичный доступ? Около одного человека высокой квалификации, не считая подстраховки. При этом на security research у него, скорее всего, будет недостаточно времени. > Разве не сложнее прошерстить всё перед > выпуском дистрибутива? Можно ведь получить ситуацию как с виндой, когда > ставится изначально "дырявая" ОС, для которой все исправления доступны, > но поставить их не успеваешь, потому как время жизни такой ОС в сети > значительно меньше времени скачивания этих исправлений :) За тем, чтобы пакет в Сизифе был свежим, должен следить мантейнер, а все остальные должны ему помогать, хотя бы через bugzilla. У нас даже есть несколько хорошо зарекомендовавших себя мантейнеров, которых secoff по возможности информирует об уязвимостях заранее. > >>>Если бы мантейнеры действительно заботились о безопасности своих пакетов, > >>>то вопрос информирования не стоял бы. > >>> > Майнтейнер майнтейнеру рознь. Ведь они это не за зарплату делают и это > не их основная задача. Кому-то все равно, есть ли remote access к этому > приложению, потому как у него и сети нет на этой машине и пользуется он > один этим. А кто-то использует это по полной программе. Причем, > майнтейнер может быть вообще в астрале и не реагировать на письма. Что > делать второму? Постоянно следить за пакетом, не надеясь на первого и > при первой же уязвимости делать NMU? Понятно, что вариантов масса и > всего учесть нельзя. Мы переходим на gear, с помощью которого кооперативная работа будет происходить гораздо проще и эффективней. > >>Но ведь активности майнтейнеров недостаточно. Должен (читай: желательно) > >>быть какой-то человек, хоть каким-то образом отвечающий хотя бы за > >>безопасность пакетов. > > > >Что значит "отвечающий"? > > > Ну ведь есть же такое понятие Security Officer. Живьем я их еще не > видел, но знаю, что они есть :) И можно только предполагать, какой > процент компаний может себе позволить держать штат таких сотрудников для > каждого направления в безопасности. Компания, занимающаяся разработкой и > продажей дистрибутивов, позволить себе это может, в прямом или косвенном > виде. Хотя и это тоже все относительно... Приходите в офис компании ALT Linux, там есть (всего лишь) один такой сотрудник, который по совместительству ещё и secoff. :) На самом деле число имён пакетов, ошибки в которых были признаны уязвимостями, за год не так уж и велико, их реально проверить. > >>того, как я узнал о них случайно где-то на форуме или в личном письме, > >>уж не помню. Никто не удосужился уведомить меня о них и в Сизифе было > >>приложения с remote hole. Если внимательно посмотреть, то подобных > >>проблемных пакетов наберётся немало, imho. Разве это нормально? > > > >Видите ли, пакетов в Сизифе столько, что не интересно не только следить за > >безопасностью их всех, но и просто за их именами. > >Есть мантейнер не следит за своими пакетами, то это не мантейнер, а > >муляж мантейнера. > > > Понятно, что сферический майнтейнер в вакууме представляет значительно > больше интереса для всех, но реальность далека от этого, к сожалению. Я > так понимаю, что нормальная практика в том случае, если я перестаю > использовать приложение, это написать всем, что оно мне больше не нужно > и или забирайте его себе или выкидывайте из репозитария? Логично. > >>p.s. Я повторю вопрос: что будет после "заморозки" среза Сизифа? Будет > >>ли кто-нибудь анализировать срез на предмет безопасности? > > > >Не думаю, что имеет смысл "анализировать срез на предмет безопасности". > >Надо просто следить за своими пакетами. > > > >P.S. Всех учу, а самому никак libtiff новый собрать некогда. :( > > > А как можно за ними за всеми следить? Вот только что глянул на Top > maintainers на sisyphus.ru (все знают, кто там :). В жизни не поверю, > что кто-то из них физически способен следить за своими пакетами, даже > если он этим будет заниматься 24/7 :) А вот если коллективно, то хоть > что-то получится. Следить, на самом деле, не так уж и сложно. Вот, нашёл публичную ссылку: http://www.google.com/search?q=%22vendor-sec%20mailing%20list%22&num=1 -- ldv