[devel] severity "security"

[devel] severity "security"

[Andrew Kornilov]

Добрый день.

А не сделать ли нам severity "security" в bugzilla? И каким-то образом 
постараться сделать добавление бага максимально авторизированным. Очень 
хочется видеть, какие же пакеты у нас дырявые на данный момент. bugtraq 
читают многие, я думаю. Но ситуацию с security, похоже, никто не 
отслеживает совершенно.

p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", 
что будет после заморозки? Некие специальные люди будут читать весь 
архив bugtraq и анализировать текущие версии пакетов на предмет 
уязвимостей  или это будет выпущено as is?

Re: [devel] severity "security"

[Michael Shigorin]

On Fri, Jun 16, 2006 at 07:00:58PM +0300, Andrew Kornilov wrote:
> p.s. Интересно, если, к примеру, если будет выпускаться новый
> "Master", что будет после заморозки?

Главное, чтоб не как обычно.

PS: с дырками, как и с багами, у нас явно больше проблем со
временем на исправление, чем с повешением...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] severity "security"

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Hi,

On Fri, Jun 16, 2006 at 07:00:58PM +0300, Andrew Kornilov wrote:
> А не сделать ли нам severity "security" в bugzilla? И каким-то образом 
> постараться сделать добавление бага максимально авторизированным.

Какой в этом смысл?
Постящий bug report и так может пометить его как security.

> Очень хочется видеть, какие же пакеты у нас дырявые на данный момент.

Зачем?

> bugtraq читают многие, я думаю.

Не факт.  Этот список рассылки последнее время стал малоинформативным.

> Но ситуацию с security, похоже, никто не отслеживает совершенно.

Ну, тут вы сильно заблуждаетесь. :)

> p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", 
> что будет после заморозки? Некие специальные люди будут читать весь 
> архив bugtraq и анализировать текущие версии пакетов на предмет 
> уязвимостей  или это будет выпущено as is?

Коллега, вот я бы на вашем месте подумал, что будет в плане задраивания
отверстий в пакетах уже после релиза.

Если бы мантейнеры действительно заботились о безопасности своих пакетов,
то вопрос информирования не стоял бы.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] severity "security"

[Andrew Kornilov]

Dmitry V. Levin wrote:

>Какой в этом смысл?
>Постящий bug report и так может пометить его как security.
>  
>
Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы 
не увидит описание проблемы, во-вторых, как мне найти такие уязвимые 
приложения в поиске?

>>Очень хочется видеть, какие же пакеты у нас дырявые на данный момент.
>>    
>>
>
>Зачем?
>  
>
Чтобы видеть, с какими пакетами проблемы. Неработоспособность видна 
сразу обычно, как быть с безопасностью? Если бы был некий список 
уязвимостей приложения и их статуc в Сизифе, было бы проще  узнать, 
можно ли его использовать в данный момент. Вот кто сходу может ответить, 
можно ли использовать нашу сборку openvpn? А sshd? А как быть с 
утилитами типа rkhunter, которые проверяют версию приложения? Он ведь 
упорно ругается на наш sshd как на уязвимый, хотя это и не так. Кому 
верить?  Как проверить?

>>bugtraq читают многие, я думаю.
>>    
>>
>
>Не факт.  Этот список рассылки последнее время стал малоинформативным.
>  
>
Но как быть тогда? Аналога полноценного нет. Но это ведь не повод 
игнорировать вообще проблемы с безопасностью.

>>Но ситуацию с security, похоже, никто не отслеживает совершенно.
>>    
>>
>
>Ну, тут вы сильно заблуждаетесь. :)
>  
>
Я очень на это надеюсь. Но очень хочется увидеть какие-либо упоминания 
об этом, а еще лучше результаты.

>>p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", 
>>что будет после заморозки? Некие специальные люди будут читать весь 
>>архив bugtraq и анализировать текущие версии пакетов на предмет 
>>уязвимостей  или это будет выпущено as is?
>>    
>>
>
>Коллега, вот я бы на вашем месте подумал, что будет в плане задраивания
>отверстий в пакетах уже после релиза.
>  
>
Не совсем понял. То есть, выпустить дистрибутив с уязвимостями можно, 
главное, чтобы потом кто-то их исправлял?

>Если бы мантейнеры действительно заботились о безопасности своих пакетов,
>то вопрос информирования не стоял бы.
>
>  
>
Но ведь активности майнтейнеров недостаточно. Должен (читай: желательно) 
быть какой-то человек, хоть каким-то образом отвечающий хотя бы за 
безопасность пакетов. Ведь те же orphaned-пакеты у нас выкидываются из 
Сизифа без малейшего сожаления, почему бы не выкидывать оттуда и 
небезопасные приложения (можно ведь и автоматически). Я даже из личного 
опыта добавлю: у меня хоть и мало пакетов, но следить за их развитием не 
хватает времени. О проблемах безопасности я узнаю/узнавал случайно. 
Описание багов  одного приложения проходило в bugtraq за ~ месяц до 
того, как я узнал о них случайно где-то на форуме или в личном письме, 
уж не помню. Никто не удосужился уведомить меня о них и в Сизифе было 
приложения с remote hole. Если внимательно посмотреть, то подобных 
проблемных пакетов наберётся немало, imho.  Разве это нормально?

p.s. Я повторю вопрос: что будет после "заморозки" среза Сизифа? Будет 
ли кто-нибудь анализировать срез на предмет безопасности?

Re: [devel] severity "security"

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 5288 bytes --]

On Fri, Jun 16, 2006 at 11:10:11PM +0300, Andrew Kornilov wrote:
> Dmitry V. Levin wrote:
> 
> >Какой в этом смысл?
> >Постящий bug report и так может пометить его как security.
> >
> Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы 
> не увидит описание проблемы,

Предполагается, что для этой группы ошибок важна конфиденциальность.

> во-вторых, как мне найти такие уязвимые приложения в поиске?

Отметить эту группу в поиске (если вы входите в соответствующую группу).

> >>Очень хочется видеть, какие же пакеты у нас дырявые на данный момент.
> >
> >Зачем?
> >
> Чтобы видеть, с какими пакетами проблемы. Неработоспособность видна 
> сразу обычно, как быть с безопасностью?

Пойдите на http://cve.mitre.org/cve/ и посмотрите.

> Если бы был некий список 
> уязвимостей приложения и их статуc в Сизифе, было бы проще  узнать, 
> можно ли его использовать в данный момент. Вот кто сходу может ответить, 
> можно ли использовать нашу сборку openvpn? А sshd? А как быть с 
> утилитами типа rkhunter, которые проверяют версию приложения? Он ведь 
> упорно ругается на наш sshd как на уязвимый, хотя это и не так. Кому 
> верить?  Как проверить?

Либо я вас не понял, либо вы наивно полагаете, что дырявость пакета так же
легко проверяется, как и собираемость.

Хотя есть, конечно, разные категории пакетов.
Например, есть такая категория пакетов, про которые известно, что они
дырявые от природы.

Как вы можете проверить, является ли пакет openssh в Сизифе уязвимым?
Это зависит от вашей профессиональной подготовки.

Давайте это проверим.  Ответьте, по возможности, аргументированно на такой
вопрос: подвержен ли уязвимости CVE-2006-2607 пакет vixie-cron в Сизифе?
Как бы вы стали проверять crond на CVE-2006-2607?  Вешать багу на пакет?

> >>bugtraq читают многие, я думаю.
> >
> >Не факт.  Этот список рассылки последнее время стал малоинформативным.
> >
> Но как быть тогда? Аналога полноценного нет.

Это не так.  Есть много списков рассылок, которые вместе взятые дают
достаточно полную картину того, какие пакеты и на какую тему _принято_
исправлять.

> Но это ведь не повод игнорировать вообще проблемы с безопасностью.

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

Видите ли, если к безопасности относиться серьёзно, то это сложная
многослойная задача.

> >>Но ситуацию с security, похоже, никто не отслеживает совершенно.
> >
> >Ну, тут вы сильно заблуждаетесь. :)
> >
> Я очень на это надеюсь. Но очень хочется увидеть какие-либо упоминания 
> об этом, а еще лучше результаты.

Я определённо не понимаю, какое упоминание и какой результат вы хотите увидеть.

> >>p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", 
> >>что будет после заморозки? Некие специальные люди будут читать весь 
> >>архив bugtraq и анализировать текущие версии пакетов на предмет 
> >>уязвимостей  или это будет выпущено as is?
> >
> >Коллега, вот я бы на вашем месте подумал, что будет в плане задраивания
> >отверстий в пакетах уже после релиза.
> >
> Не совсем понял. То есть, выпустить дистрибутив с уязвимостями можно, 
> главное, чтобы потом кто-то их исправлял?

Я имею в виду, что исправлять уязвимости в уже выпущенном дистрибутиве
в течение всего срока его жизни существенно сложнее, чем выпустить
дистрибутив с заткнутыми опубликованными дырками.

> >Если бы мантейнеры действительно заботились о безопасности своих пакетов,
> >то вопрос информирования не стоял бы.
> >
> Но ведь активности майнтейнеров недостаточно. Должен (читай: желательно) 
> быть какой-то человек, хоть каким-то образом отвечающий хотя бы за 
> безопасность пакетов.

Что значит "отвечающий"?

> Ведь те же orphaned-пакеты у нас выкидываются из 
> Сизифа без малейшего сожаления, почему бы не выкидывать оттуда и 
> небезопасные приложения (можно ведь и автоматически). Я даже из личного 
> опыта добавлю: у меня хоть и мало пакетов, но следить за их развитием не 
> хватает времени. О проблемах безопасности я узнаю/узнавал случайно. 
> Описание багов  одного приложения проходило в bugtraq за ~ месяц до 
> того, как я узнал о них случайно где-то на форуме или в личном письме, 
> уж не помню. Никто не удосужился уведомить меня о них и в Сизифе было 
> приложения с remote hole. Если внимательно посмотреть, то подобных 
> проблемных пакетов наберётся немало, imho.  Разве это нормально?

Видите ли, пакетов в Сизифе столько, что не интересно не только следить за
безопасностью их всех, но и просто за их именами.
Есть мантейнер не следит за своими пакетами, то это не мантейнер, а
муляж мантейнера.

> p.s. Я повторю вопрос: что будет после "заморозки" среза Сизифа? Будет 
> ли кто-нибудь анализировать срез на предмет безопасности?

Не думаю, что имеет смысл "анализировать срез на предмет безопасности".
Надо просто следить за своими пакетами.

P.S. Всех учу, а самому никак libtiff новый собрать некогда. :(


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] severity "security"

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

On Fri, Jun 16, 2006 at 11:10:11PM +0300, Andrew Kornilov wrote:
> А как быть с утилитами типа rkhunter, которые проверяют версию
> приложения?

Так и быть -- выкинуть как ориентированный на слаквари.
Ну или помнить цену выводу.

> Кому верить?

Каждый решает сам.

> Как проверить?

pen-test и metasploit? (мне не настолько интересно, чтобы
высказать _своё_ мнение -- его тут нет)

> >>bugtraq читают многие, я думаю.
> >Не факт.  Этот список рассылки последнее время стал
> >малоинформативным.
> Но как быть тогда? Аналога полноценного нет. Но это ведь не
> повод игнорировать вообще проблемы с безопасностью.

Рекомендую анонсы secunia.com.  Описания у них порой до того
шаблонные, что напоминают спам, но по крайней мере есть ссылки,
батчами и довольно оперативно.

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

Выпустить дистрибутив без уязвимостей (не обязательно известных)
нельзя.  Говорят, безопасность -- не состояние, а процесс.

> >Если бы мантейнеры действительно заботились о безопасности
> >своих пакетов, то вопрос информирования не стоял бы.
> Но ведь активности майнтейнеров недостаточно. Должен (читай:
> желательно) быть какой-то человек, хоть каким-то образом
> отвечающий хотя бы за безопасность пакетов.

Всех?

> Ведь те же orphaned-пакеты у нас выкидываются из Сизифа без
> малейшего сожаления, почему бы не выкидывать оттуда и
> небезопасные приложения (можно ведь и автоматически).

sendmail безопасен?  (Сергей, простите!  ничего личного)

> Я даже из личного опыта добавлю: у меня хоть и мало пакетов, но
> следить за их развитием не хватает времени. О проблемах
> безопасности я узнаю/узнавал случайно.  Описание багов  одного
> приложения проходило в bugtraq за ~ месяц до того, как я узнал
> о них случайно где-то на форуме или в личном письме, уж не
> помню. Никто не удосужился уведомить меня о них и в Сизифе было
> приложения с remote hole.

Я стараюсь форвардить то, что замечаю, тем, кого знаю, если это
касается того, что им небезынтересно.  Просто все списки "кому
чего" в голове, естественно, не поместить.

Знаю как минимум одного человека, который порой вешает толковые
баги именно по части безопасности (Serg Rychka).

> p.s. Я повторю вопрос: что будет после "заморозки" среза
> Сизифа? Будет ли кто-нибудь анализировать срез на предмет
> безопасности?

PS: чего и удивился, когда упразднили компоненты -- main и
contrib всё-таки вполне возможно разделить, проведя формальный
опрос -- за что кто готов отвечать и _оценочно_ -- насколько
долго и в какой мере.  За несколько из своих пакетов могу
подписаться, пересматривал их тогда в таком свете.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] severity "security"

[Andrew Kornilov]

Dmitry V. Levin wrote:

Пардон, что так затянул с ответом :(

>>>Какой в этом смысл?
>>>Постящий bug report и так может пометить его как security.
>>>      
>>>
>>Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы 
>>не увидит описание проблемы,
>>    
>>
>
>Предполагается, что для этой группы ошибок важна конфиденциальность.
>  
>
Для всех пакетов? А зачем? Я понимаю, когда есть серьезная уязвимость и 
exploit для неё и это приложение используется повсеместно. Но ведь 
ежедневно находят немалое количество не очень серьезных уязвимостей, 
которые, однако, исправить нужно в обозримом будущем. Если нет общей 
системы для их учета, то приходится их писать на бумажке/в файле. И 
читать одному человеку все рассылки по уязвимостям несколько 
проблематично. Если уж элементарные баги сам найти не можешь в своем же 
и используемом самим же пакете, тогда как другие натыкаются на это 
сразу, то с этими уязвимостями ситуация еще хуже.

>>Чтобы видеть, с какими пакетами проблемы. Неработоспособность видна 
>>сразу обычно, как быть с безопасностью?
>>    
>>
>
>Пойдите на http://cve.mitre.org/cve/ и посмотрите.
>  
>
Там не всё. Вот только что приехала уязвимость на OpenVPN: DoS, System 
Access; на mitre.org её нет. Что мне делать? Ждать, когда об этом узнает 
майнтейнер, повесить баг, пересобрать самому?

>>Если бы был некий список 
>>уязвимостей приложения и их статуc в Сизифе, было бы проще  узнать, 
>>можно ли его использовать в данный момент. Вот кто сходу может ответить, 
>>можно ли использовать нашу сборку openvpn? А sshd? А как быть с 
>>утилитами типа rkhunter, которые проверяют версию приложения? Он ведь 
>>упорно ругается на наш sshd как на уязвимый, хотя это и не так. Кому 
>>верить?  Как проверить?
>>    
>>
>
>Либо я вас не понял, либо вы наивно полагаете, что дырявость пакета так же
>легко проверяется, как и собираемость.
>  
>
Неплохо бы иметь список проблем из разных источников, чтобы не метаться 
по всем рассылкам. Да и security hole может быть и не из-за уязвимости 
самого приложения, а из-за того, что майнтейнер установил некую опцию 
типа RemoteRootAccess=yes. Ну и т.д.

>Хотя есть, конечно, разные категории пакетов.
>Например, есть такая категория пакетов, про которые известно, что они
>дырявые от природы.
>  
>
Но иногда и они нужны, когда больше никто подобную функциональность не 
предоставляет.  Можно его как-то пометить, мол, вечно уязвимый, но 
оставить. Я помню ситуацию с ntop несколько лет назад, когда мне 
преложили его поместить в какой-то определенный каталог с "плохими" 
приложениями, когда я предложел его в сизифе разместить :)

>Как вы можете проверить, является ли пакет openssh в Сизифе уязвимым?
>Это зависит от вашей профессиональной подготовки.
>
>Давайте это проверим.  Ответьте, по возможности, аргументированно на такой
>вопрос: подвержен ли уязвимости CVE-2006-2607 пакет vixie-cron в Сизифе?
>Как бы вы стали проверять crond на CVE-2006-2607?  Вешать багу на пакет?
>  
>
Понятия не имею. У меня нет перез глазами явного списка всех его 
уязвимостей. И исправлена ли она, я могу (с трудом) определить, почитав 
изначально --changelog (и поверим майнтейнеру, который написал там, мол, 
исправлено), могу почитать про уязвимость, посмотреть исправления, 
заглянуть в код и с некоей долей вероятности определить, что, видимо, 
[не]исправлено. И это ведь достаточно мелкий пакет. А их ведь сто тыщ 
миллионов :(

>>>>bugtraq читают многие, я думаю.
>>>>        
>>>>
>>>Не факт.  Этот список рассылки последнее время стал малоинформативным.
>>>      
>>>
>>Но как быть тогда? Аналога полноценного нет.
>>    
>>
>
>Это не так.  Есть много списков рассылок, которые вместе взятые дают
>достаточно полную картину того, какие пакеты и на какую тему _принято_
>исправлять.
>  
>
И все эти списки рассылки должен читать каждый майнтейнер? Я думаю, что 
на это не согласятся даже за деньги :-)

>  
>
>>Но это ведь не повод игнорировать вообще проблемы с безопасностью.
>>    
>>
>
>Нет, конечно.  Но мне кажется, что ваш взгляд на этот вопрос несколько
>упрощённый.  Припоминаю, как несколько лет назад непосредственно перед
>релизом какой-то версии Mandrake была найдена какая-то довольно глупая
>ошибка в их пакете SysVinit, после чего один пользователь написал в список
>рассылки предложение быстренько проверить и устранить оставшиеся дырки. :)
>
>Видите ли, если к безопасности относиться серьёзно, то это сложная
>многослойная задача.
>  
>
Да это все понятно. Но сейчас мне вообще непонятно, кто и что проверяет 
и контролирует. И есть ли это вообще. Я могу быть майнтенером мелкой 
утилиты, которую мало кто использует, но она есть в базовой системе и 
для неё уже два года как local root exploit есть. Что с ней будет? 
Видимо, ничего.

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

>>>>p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", 
>>>>что будет после заморозки? Некие специальные люди будут читать весь 
>>>>архив bugtraq и анализировать текущие версии пакетов на предмет 
>>>>уязвимостей  или это будет выпущено as is?
>>>>        
>>>>
>>>Коллега, вот я бы на вашем месте подумал, что будет в плане задраивания
>>>отверстий в пакетах уже после релиза.
>>>      
>>>
>>Не совсем понял. То есть, выпустить дистрибутив с уязвимостями можно, 
>>главное, чтобы потом кто-то их исправлял?
>>    
>>
>Я имею в виду, что исправлять уязвимости в уже выпущенном дистрибутиве
>в течение всего срока его жизни существенно сложнее, чем выпустить
>дистрибутив с заткнутыми опубликованными дырками.
>  
>
Насколько сложно? Сколько нужно людей на fulltime, чтобы исправлять в 
среднем, одну уязвимость в день, пересобирать пакет, как-то тестировать 
и выкладывать в публичный доступ? Разве не сложнее прошерстить всё перед 
выпуском дистрибутива? Можно ведь получить ситуацию как с виндой, когда 
ставится изначально "дырявая" ОС, для которой все исправления доступны, 
но поставить их не успеваешь, потому как время жизни такой ОС в сети 
значительно меньше времени скачивания этих исправлений :)

>>>Если бы мантейнеры действительно заботились о безопасности своих пакетов,
>>>то вопрос информирования не стоял бы.
>>>      
>>>
Майнтейнер майнтейнеру рознь. Ведь они это не за зарплату делают и это 
не их основная задача. Кому-то все равно, есть ли remote access к этому 
приложению, потому как у него и сети нет на этой машине и пользуется он 
один этим. А кто-то использует это по полной программе. Причем, 
майнтейнер может быть вообще в астрале и не реагировать на письма. Что 
делать второму? Постоянно следить за пакетом, не надеясь на первого и 
при первой же уязвимости делать NMU? Понятно, что вариантов масса и 
всего учесть нельзя.

>>>      
>>>
>>Но ведь активности майнтейнеров недостаточно. Должен (читай: желательно) 
>>быть какой-то человек, хоть каким-то образом отвечающий хотя бы за 
>>безопасность пакетов.
>>    
>>
>
>Что значит "отвечающий"?
>  
>
Ну ведь есть же такое понятие Security Officer. Живьем я их еще не 
видел, но знаю, что они есть :) И можно только предполагать, какой 
процент компаний может себе позволить держать штат таких сотрудников для 
каждого направления в безопасности. Компания, занимающаяся разработкой и 
продажей дистрибутивов, позволить себе это может, в прямом или косвенном 
виде. Хотя и это тоже все относительно...

>>того, как я узнал о них случайно где-то на форуме или в личном письме, 
>>уж не помню. Никто не удосужился уведомить меня о них и в Сизифе было 
>>приложения с remote hole. Если внимательно посмотреть, то подобных 
>>проблемных пакетов наберётся немало, imho.  Разве это нормально?
>>    
>>
>
>Видите ли, пакетов в Сизифе столько, что не интересно не только следить за
>безопасностью их всех, но и просто за их именами.
>Есть мантейнер не следит за своими пакетами, то это не мантейнер, а
>муляж мантейнера.
>  
>
Понятно, что сферический майнтейнер в вакууме представляет значительно 
больше интереса для всех, но реальность далека от этого, к сожалению. Я 
так понимаю, что нормальная практика в том случае, если я перестаю 
использовать приложение, это написать всем, что оно мне больше не нужно 
и или забирайте его себе или выкидывайте из репозитария?

>>p.s. Я повторю вопрос: что будет после "заморозки" среза Сизифа? Будет 
>>ли кто-нибудь анализировать срез на предмет безопасности?
>>    
>>
>
>Не думаю, что имеет смысл "анализировать срез на предмет безопасности".
>Надо просто следить за своими пакетами.
>
>P.S. Всех учу, а самому никак libtiff новый собрать некогда. :(
>  
>
А как можно за ними за всеми следить? Вот только что глянул на Top 
maintainers на sisyphus.ru (все знают, кто там :). В жизни не поверю, 
что кто-то из них физически способен следить за своими пакетами, даже 
если он этим будет заниматься 24/7 :) А вот если коллективно, то хоть 
что-то получится.

p.s. В общем, это всё лирика пока, конечно. Но что-то полезное и 
интересное придумать можно, если не быть столь консервативным :) Чукча, 
к сожалению, больше читатель, чем писатель, поэтому от меня конструктива 
дождаться сложно. Может кто присоединится.

Re: [devel] severity "security"

[Andrew Kornilov]

Michael Shigorin wrote:

И тут сорри за задержку.

>>А как быть с утилитами типа rkhunter, которые проверяют версию
>>приложения?
>>    
>>
>Так и быть -- выкинуть как ориентированный на слаквари.
>Ну или помнить цену выводу.
>
>  
>
С большей вероятность можно верить багзилле, в которой будет список CVE 
и рядом пунктик, исправлена или нет :)

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

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

>>>Если бы мантейнеры действительно заботились о безопасности
>>>своих пакетов, то вопрос информирования не стоял бы.
>>>      
>>>
>>Но ведь активности майнтейнеров недостаточно. Должен (читай:
>>желательно) быть какой-то человек, хоть каким-то образом
>>отвечающий хотя бы за безопасность пакетов.
>>    
>>
>
>Всех?
>  
>
Принимающий решение хотя бы. Типа: нет исправления - не место этому 
пакету здесь.

>>Ведь те же orphaned-пакеты у нас выкидываются из Сизифа без
>>малейшего сожаления, почему бы не выкидывать оттуда и
>>небезопасные приложения (можно ведь и автоматически).
>>    
>>
>
>sendmail безопасен?  (Сергей, простите!  ничего личного)
>  
>
Сложно сказать :) Он может быть безопасен сам по себе, по содержать 
такой конфиг по умолчнию, что станет отличной добычей для спамеров.

>Я стараюсь форвардить то, что замечаю, тем, кого знаю, если это
>касается того, что им небезынтересно.  Просто все списки "кому
>чего" в голове, естественно, не поместить.
>  
>
Вот и я о чем. Невозможно это все держать в голове. Можно где-то 
помечать. В качестве бага хотя бы. Я изначально предложил всего лишь 
severity "security". Можно, конечно, и блокерами это всё обзывать :)

>Знаю как минимум одного человека, который порой вешает толковые
>баги именно по части безопасности (Serg Rychka).
>  
>
Честь ему и хвала. Не то, что я, ленивый.

>  
>
>>p.s. Я повторю вопрос: что будет после "заморозки" среза
>>Сизифа? Будет ли кто-нибудь анализировать срез на предмет
>>безопасности?
>>    
>>
>
>PS: чего и удивился, когда упразднили компоненты -- main и
>contrib всё-таки вполне возможно разделить, проведя формальный
>опрос -- за что кто готов отвечать и _оценочно_ -- насколько
>долго и в какой мере.  За несколько из своих пакетов могу
>подписаться, пересматривал их тогда в таком свете.
>  
>
Но если я не выполняют это обязательство, должен кто-то недрогнувшей 
рукой забрать у меня пакет или выкинуть его. А так, пока никто бучу не 
поднял, все отмалчиваются :)

Re: [devel] severity "security"

[Michael Shigorin]

On Mon, Oct 02, 2006 at 08:10:09PM +0300, Andrew Kornilov wrote:
> >Пойдите на http://cve.mitre.org/cve/ и посмотрите.
> Там не всё. Вот только что приехала уязвимость на OpenVPN: DoS,
> System Access; на mitre.org её нет. Что мне делать? Ждать,
> когда об этом узнает майнтейнер, повесить баг, пересобрать
> самому?

Уведомить майнтейнера, пересобрать самому и закинуть в
/incoming/updates, если заработало (если есть тесткейс
-- соответственно проверив им).

> >Либо я вас не понял, либо вы наивно полагаете, что дырявость
> >пакета так же легко проверяется, как и собираемость.
> Неплохо бы иметь список проблем из разных источников, чтобы не
> метаться по всем рассылкам.

Подпишись на рассылку secunia.com, вполне адекватно IMHO.
Ну и раз озадачился -- на security-team@.

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

Для этого требуются:

- security response team (на ставке или добровольная);
- (желательно) тестировщики исправлений;
- (желательно) писатели анонсов или 
- внятные changelog и робот-чтец к ним.

Для Sisyphus мне кажется осмысленным разве что нечто
дебиановского urgency в changelog добавлять каким-то
единообразным макаром.

> Майнтейнер майнтейнеру рознь. Ведь они это не за зарплату
> делают и это не их основная задача. Кому-то все равно, есть ли
> remote access к этому приложению, потому как у него и сети нет
> на этой машине и пользуется он один этим. А кто-то использует
> это по полной программе. Причем, майнтейнер может быть вообще в
> астрале и не реагировать на письма. Что делать второму?
> Постоянно следить за пакетом, не надеясь на первого и при
> первой же уязвимости делать NMU? Понятно, что вариантов масса и
> всего учесть нельзя.

Вот для чего big incoming lock и надо решать, в частности.
Поскольку порой одни заинтересованы в развитии и поддержании
функциональности пакета, а другие -- безопасности, и без
доступной по цене (времени) возможности сотрудничать это 
не работает.

> >>p.s. Я повторю вопрос: что будет после "заморозки" среза
> >>Сизифа? Будет ли кто-нибудь анализировать срез на предмет
> >>безопасности?
> >Не думаю, что имеет смысл "анализировать срез на предмет
> >безопасности".  Надо просто следить за своими пакетами.
> >P.S. Всех учу, а самому никак libtiff новый собрать некогда. :(
> А как можно за ними за всеми следить? Вот только что глянул на
> Top maintainers на sisyphus.ru (все знают, кто там :). В жизни
> не поверю, что кто-то из них физически способен следить за
> своими пакетами, даже если он этим будет заниматься 24/7 :)
> А вот если коллективно, то хоть что-то получится.

Мне кажется, может помочь институт лейтенантов -- в плане
"собрать свежую версию, благо ничего притирать особо не надо",
"закинуть патчи в апстрим", "подстраховать по сборке апдейта".

Вот только где брать ответственных студентов, которые достаточно
сильно дружат с головой, чтобы ценить такой экспириенс нахаляву
-- пока не совсем понятно.

> p.s. В общем, это всё лирика пока, конечно. Но что-то полезное
> и интересное придумать можно, если не быть столь консервативным
> :) Чукча, к сожалению, больше читатель, чем писатель, поэтому
> от меня конструктива дождаться сложно. Может кто присоединится.

Давай для начала поддержим инициативу Димы насчёт git.alt руками.
Это часть решения блокировки распределённой работы.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] severity "security"

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Mon, Oct 02, 2006 at 08:10:09PM +0300, Andrew Kornilov wrote:
> Dmitry V. Levin wrote:
> 
> Пардон, что так затянул с ответом :(

Пожалуй, я тоже затяну с ответом на несколько лет, к тому времени вы сами
найдёте ответы на эти вопросы. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] severity "security"

[Nikolay A. Fetisov]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On Mon, 02 Oct 2006 20:10:09 +0300
Andrew Kornilov wrote:

> ....
> >Пойдите на http://cve.mitre.org/cve/ и посмотрите.
> >  
> Там не всё. Вот только что приехала уязвимость на OpenVPN: DoS, System 
> Access; на mitre.org её нет. 

Пример не удачный, если Вы об этом:
http://secunia.com/advisories/22232/ ,
"The OpenVPN Windows Installer prior to 2.0.9 includes vulnerable
versions of the OpenSSL DLL files."

К сборкам OpenVPN в Sisyphus, Compact 3.0 и Master 2.4 данная
уязвимость отношения напрямую не имеет; ошибки в библиотеках
OpenSSL закрыты в Sisyphus и Master 2.4.

Просто так обновлять пакет до 2.0.9 я большого смысла не вижу, в
Unix-коде там не было изменений с 2.0.7, т.е. с  апреля этого года.


> Что мне делать? Ждать, когда об этом узнает майнтейнер, 
> повесить баг, пересобрать самому?

Как уже было сказано, наверное, стоило бы:
- сообщить майнтейнеру,
- повесить ошибку в bugzilla, с указанием источника сообщения об
уязвимости и описанием её,
- далее, по возможности/желанию/прочему - сборка исправленной версии, с
размещением патчей как приложений к ошибке.


-- 
С уважением,	
Николай Фетисов

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] [wiki] Re: severity "security"

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Mon, Oct 02, 2006 at 11:40:29PM +0400, Nikolay A. Fetisov wrote:
> > Что мне делать? Ждать, когда об этом узнает майнтейнер, 
> > повесить баг, пересобрать самому?
> Как уже было сказано, наверное, стоило бы:
> - сообщить майнтейнеру,
> - повесить ошибку в bugzilla, с указанием источника сообщения об
> уязвимости и описанием её,
> - далее, по возможности/желанию/прочему - сборка исправленной версии, с
> размещением патчей как приложений к ошибке.

Создал http://www.freesource.info/wiki/AltLinux/Security

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] severity "security"

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 11870 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]