The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от opennews (??) on 24-Сен-11, 11:34 
Под конец только что завершившегося хакатона (http://www.openbsd.org/hackathons.html) s2k11 в Словении, в базовую систему импортирован (http://marc.info/?l=openbsd-cvs&m=131673440721777&w=2) http-сервер nginx (http://www.nginx.ru/), развиваемый Игорем Сысоевым (http://www.sysoev.ru/). В ближайшем будущем планируется, что nginx займёт место Apache 1.3 в базовой системе OpenBSD. На данный момент nginx не включён в сборку, так как требуется решить ещё несколько технических вопросов, таких как использование встроенной PCRE-библиотеки, совмещение chroot, лог-файлов и обновления конфигурации.


Это далеко не единственное, что происходит в рамках разработки OpenBSD:


-  Полным ходом идут работы над полноценной загрузкой с softraid(4) (http://www.openbsd.org/cgi-bin/man.cgi?query=softraid&sektio...): корневой раздел в -CURRENT уже можно использовать прямо с softraid без ухищрений, но ядро пока что должно грузиться с отдельного диска;

-  Готовится подд...

URL:
Новость: https://www.opennet.ru/opennews/art.shtml?num=31843

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +7 +/
Сообщение от Аноним (??) on 24-Сен-11, 11:34 
Давно пора.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от Аноним (??) on 24-Сен-11, 11:39 
>Поддержка работы одновременно нескольких экземпляров ntpd(8), что бывает нужно при использовании нескольких доменов маршрутизации;

Не понял, в чем принципиальная разница нескольких экземпляров ntpd и одного, слушающего разные айпишники, с точки зрения маршрутизации?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Сен-11, 12:19 
>>Поддержка работы одновременно нескольких экземпляров ntpd(8), что бывает нужно при использовании нескольких доменов маршрутизации;
> Не понял, в чем принципиальная разница нескольких экземпляров ntpd и одного, слушающего
> разные айпишники, с точки зрения маршрутизации?

Один процесс ntpd может слушать сразу на нескольких айпишниках, это-то ни разу не проблема. Но в пределах одного домена маршрутизации, так как он устанавливается в рамках процесса. Соответственно, чтобы использовать NTP в нескольких доменах маршрутизации одновременно, нужно запускать несколько экземпляров ntpd. А к чему приводит простой запуск нескольких синхронизирующих демонов одновременно, думаю, объяснять не надо. Поэтому потребовалось ntpd немного доработать, чтобы несколько экземпляров не мешали друг другу.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от НонАнон on 24-Сен-11, 13:06 
А, имеется ввиду запуск процесса с альтернативной таблицей маршрутизации, вроде setfib у FreeBSD.. Понятно.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 24-Сен-11, 13:08 
Покруче чем Freebsd. В openbsd в каком то виде MPLS уже есть.
Правда говорят что совсем не для продакшена.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Сен-11, 13:19 
> Покруче чем Freebsd. В openbsd в каком то виде MPLS уже есть.
> Правда говорят что совсем не для продакшена.

Ну, когда только-только импортировали да. Несколько разработчиков его используют, багфиксы появляются уже редко, так что, похоже, стабилизировалось. Сам не тестил, правда, так что это лишь мои наблюдения со стороны.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

27. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 25-Сен-11, 16:16 
>Но в пределах одного домена маршрутизации, так как он устанавливается в рамках процесса.

Может, проще будет сделать как у пингвинов, возможность выбора домена маршрутизации на основании некоторой логики (в частности, собственного айпишника)?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

30. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Сен-11, 18:33 
>>Но в пределах одного домена маршрутизации, так как он устанавливается в рамках процесса.
> Может, проще будет сделать как у пингвинов, возможность выбора домена маршрутизации на
> основании некоторой логики (в частности, собственного айпишника)?

Эм. Вот у вас два домена маршрутизации. В одном из них ваш айпишник 192.168.0.4. Во втором ваш айпишник... 192.168.0.4. Как вы будете их отличать? :)

А вообще, я выразился неправильно выше (в который раз говорю себе не выпускать в свет написанное на сон грядущий...): не несколько экземпляров ntpd теперь будет работать, а именно что один, но слушающий в нескольких доменах маршрутизации. В файле конфигурации это может выглядеть, например, так:


listen on *
listen on 192.168.5.9 rtable 5
servers ru.ntp.pool.org rtable 3

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

35. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 25-Сен-11, 20:18 
>Эм. Вот у вас два домена маршрутизации. В одном из них ваш айпишник 192.168.0.4. Во втором ваш айпишник... 192.168.0.4.

И они оба висят на одном сетевом интерфейсе, да?

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

38. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 02:27 
>>Эм. Вот у вас два домена маршрутизации. В одном из них ваш айпишник 192.168.0.4. Во втором ваш айпишник... 192.168.0.4.
> И они оба висят на одном сетевом интерфейсе, да?

Позвольте процитировать ваши слова:

>>> Может, проще будет сделать как у пингвинов, возможность выбора домена маршрутизации на
>>> основании некоторой логики (в частности, собственного айпишника)?

Слово "интерфейс" здесь отсутствует.

Что касается новой версии вашего предложения - в OpenBSD можно указать таблицу маршрутизации для конкретного сокета (опция SO_RTABLE для setsockopt(2)). Но это уже требует изменения кода программы - равно как, впрочем, и в случае любой другой "логики".

Если я вас понял неправильно, пожалуйста, поясните, о чём вы вообще говорите, какой конкретно момент вам кажется спорным.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

43. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 26-Сен-11, 14:02 
>Слово "интерфейс" здесь отсутствует.

Вы полагаете, мне стоило перечислить _все_ критерии, которые могут быть использованы в этой самой логике, не ограничиваясь одним примером? Боюсь, это была бы работа на полчаса как минимум.

>Что касается новой версии вашего предложения - в OpenBSD можно указать таблицу маршрутизации для конкретного сокета (опция SO_RTABLE для setsockopt(2)). Но это уже требует изменения кода программы - равно как, впрочем, и в случае любой другой "логики".

Пингвины используют более универсальную логику: у них есть возможность тегировать пакеты для конкретного сокета (опция SO_MARK), и на основании этих тегов обрабатывать пакеты в дальнейшем (сюда входит маршрутизация, шейпинг, фильтрация, нат, модификация заголовков и т.д.)

Кстати, инновационный пингвиний systemd позволяет использовать тегированные сокеты без модификации кода приложения (один из немногих проектов, использующих самые вкусные возможности POSIX IPC).

>Если я вас понял неправильно, пожалуйста, поясните, о чём вы вообще говорите, какой конкретно момент вам кажется спорным.

Мне кажется, механизм прямой привязки rtable к сокету несколько дубов. Возможно, достаточно было бы обеспечить поддержку тегирования трафика на сокетах, чтобы потом средствами pf выполнять дальнейшую обработку?

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

44. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 14:40 
>>Слово "интерфейс" здесь отсутствует.
> Вы полагаете, мне стоило перечислить _все_ критерии, которые могут быть использованы в
> этой самой логике, не ограничиваясь одним примером? Боюсь, это была бы
> работа на полчаса как минимум.

Все, не все, но вы бы лучше уточнили сами сразу. :) А то догадки бывают и ошибочными.

>>Что касается новой версии вашего предложения - в OpenBSD можно указать таблицу маршрутизации для конкретного сокета (опция SO_RTABLE для setsockopt(2)). Но это уже требует изменения кода программы - равно как, впрочем, и в случае любой другой "логики".
> Пингвины используют более универсальную логику: у них есть возможность тегировать пакеты
> для конкретного сокета (опция SO_MARK), и на основании этих тегов обрабатывать
> пакеты в дальнейшем (сюда входит маршрутизация, шейпинг, фильтрация, нат, модификация
> заголовков и т.д.)

Тегирование в PF делается внутри него самого (см. опции правил фильтрации "tag" и "tagged"), в остальном тот же самый принцип вполне работоспособен. ИМХО, тегировать в самом фаерволе несколько секурнее, хотя это и убирает какую-то долю гибкости.

Зато отсутствие доменов маршрутизации в Linux заметно усложняет работу, а некоторые вещи становятся чрезвычайно трудными или даже невозможными, когда в разных доменах маршрутизации используются одинаковые локальные и/или удалённые адреса. Так что OpenBSD суммарно оказывается более гибкой.

> Кстати, инновационный пингвиний systemd позволяет использовать тегированные сокеты без
> модификации кода приложения (один из немногих проектов, использующих самые вкусные возможности
> POSIX IPC).

А можно, пожалуйста, поподробнее?

>>Если я вас понял неправильно, пожалуйста, поясните, о чём вы вообще говорите, какой конкретно момент вам кажется спорным.
> Мне кажется, механизм прямой привязки rtable к сокету несколько дубов. Возможно, достаточно
> было бы обеспечить поддержку тегирования трафика на сокетах, чтобы потом средствами
> pf выполнять дальнейшую обработку?

Ну почему дубов, он скорее более очевиден для логики программы: указывая домен роутинга, программа гарантированно получает то, чего хочет. А указывая некий абстрактный тег, программа начинает зависеть от того, что там в фаерволе наконфигурировано, то есть образуется вынужденная дополнительная связь между конфигурируемыми вручную компонентами. Не смертельно, конечно, но всё же.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

47. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 26-Сен-11, 15:38 
>Зато отсутствие доменов маршрутизации в Linux заметно усложняет работу, а некоторые вещи становятся чрезвычайно трудными или даже невозможными, когда в разных доменах маршрутизации используются одинаковые локальные и/или удалённые адреса.

Вместо доменов маршрутизации там используются отдельные таблицы маршрутизации, управляемые через таблицу правил. Решение не менее фичастое, и даже более гибкое.
Приходилось иметь дело с ситуациями, когда нужно было поддерживать несколько интерфейсов с одинаковыми или пересекающимися адресными пространствами - на мой взгляд, пингвин предоставляет больше всего возможностей. А после введения conntrack zones вообще лафа пошла.

> Так что OpenBSD суммарно оказывается более гибкой.

На мой взгляд, очень спорное утверждение.

> А можно, пожалуйста, поподробнее?

Процессы могут передавать друг другу открытые fd. Такая прекрасная идея, а воспользовались ею только в launchd и в systemd (который во многом скопирован с launchd).

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

Это называется unix way: каждый инструмент решает свою задачу -> в результате имеем максимальную гибкость.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

49. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 16:49 
>>Зато отсутствие доменов маршрутизации в Linux заметно усложняет работу, а некоторые вещи становятся чрезвычайно трудными или даже невозможными, когда в разных доменах маршрутизации используются одинаковые локальные и/или удалённые адреса.
> Вместо доменов маршрутизации там используются отдельные таблицы маршрутизации, управляемые
> через таблицу правил. Решение не менее фичастое, и даже более гибкое.

Гм. А в чём принципиальное отличие от "match <...> rtable N"? (смена таблицы маршрутизации для пакета средствами PF)

> Приходилось иметь дело с ситуациями, когда нужно было поддерживать несколько интерфейсов
> с одинаковыми или пересекающимися адресными пространствами - на мой взгляд, пингвин
> предоставляет больше всего возможностей. А после введения conntrack zones вообще лафа
> пошла.

Ну да в PF нет conntrack zones, так как у PF изначально не было проблем, которые conntrack zones решают. :)

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

Ну вот, собственно, мы и спорим. :)

>> А можно, пожалуйста, поподробнее?
> Процессы могут передавать друг другу открытые fd. Такая прекрасная идея, а воспользовались
> ею только в launchd и в systemd (который во многом скопирован
> с launchd).

Понял, спасибо.

>>А указывая некий абстрактный тег, программа начинает зависеть от того, что там в фаерволе наконфигурировано, то есть образуется вынужденная дополнительная связь между конфигурируемыми вручную компонентами.
> Это называется unix way: каждый инструмент решает свою задачу -> в результате
> имеем максимальную гибкость.

Правильно. Таблица маршрутизации и фаервол - немного разные инструменты. В вашем случае обе функции ложатся на фаервол. Что вы там говорили про unix way? ;)

Всё то, что вы пока что описываете как фичи netfilter, в PF имеется (что-то давным-давно, что-то не очень). Поэтому реализовать ваш вариант можно и на OpenBSD (да и на FreeBSD как минимум тоже, ipfw местный в последнее время становится всё более человеческим). Но зачем, если есть нормально работающие домены маршрутизации? :)

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

53. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 18:02 
>> Процессы могут передавать друг другу открытые fd. Такая прекрасная идея, а воспользовались
>> ею только в launchd и в systemd (который во многом скопирован
>> с launchd).
> Понял, спасибо.

А я, вот, не понял. Передача дескрипторов требует явного вызова send/recvmsg(2), и как это сделать без  изменений в коде, не используя рантайм-враппер?

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

58. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 26-Сен-11, 19:23 
> как это сделать без  изменений в коде, не используя рантайм-враппер?

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

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

59. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 26-Сен-11, 19:40 
> Гм. А в чём принципиальное отличие от "match <...> rtable N"? (смена
> таблицы маршрутизации для пакета средствами PF)

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

> Ну да в PF нет conntrack zones, так как у PF изначально
> не было проблем, которые conntrack zones решают. :)

Он всегда умел отслеживать соединения в нескольких доменах маршрутизации? Не знал.

> Правильно. Таблица маршрутизации и фаервол - немного разные инструменты. В вашем случае
> обе функции ложатся на фаервол. Что вы там говорили про unix
> way? ;)

Авторы netfilter позиционируют его не просто как фаервол, а как "фреймворк для фильтрации и модификации пакетов". Присвоение пакету тегов - чем не модификация?
Этот же подход, кстати, справедлив и для pf. Ведь он тоже умеет не только блокировать/пропускать пакеты, правда?

Кстати, одно занудное замечание: netfilter, в отличие от pf, не имеет возможности напрямую вмешаться в процесс маршрутизации. Когда-то существовало патч, вводящий действие ROUTE, аналогичное rtable в pf, но его так и не приняли в ядро. Логика выбора таблицы реализована в самой системе маршрутизации. netfilter может лишь менять теги, являющиеся одним из критериев этой логики. Но он не является монополистом в этой области - вот в чем весь цимес.

> Всё то, что вы пока что описываете как фичи netfilter, в PF
> имеется (что-то давным-давно, что-то не очень). Поэтому реализовать ваш вариант можно
> и на OpenBSD (да и на FreeBSD как минимум тоже, ipfw
> местный в последнее время становится всё более человеческим).

В OpenBSD и FreeBSD приложения могут выставлять для своего трафика теги, которые понимает система маршрутизации?

> Но зачем, если есть нормально работающие домены маршрутизации? :)

Зачем делать гибкое модульное решение, если костыли неплохо подпирают другие костыли?
Ну, считайте меня перфекционистом :)

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

74. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 22:58 
>> Гм. А в чём принципиальное отличие от "match <...> rtable N"? (смена
>> таблицы маршрутизации для пакета средствами PF)
> Вот про это я и говорил. Еще бы добавить возможность тегирования непосредственно
> из приложения или хотя бы из враппера - и костыли можно
> будет спокойно отбросить.

Гм. Для вас домены маршрутизации - это костыли? Бывает. :)

>> Ну да в PF нет conntrack zones, так как у PF изначально
>> не было проблем, которые conntrack zones решают. :)
> Он всегда умел отслеживать соединения в нескольких доменах маршрутизации? Не знал.

Да, с момента появления доменов маршрутизации в OpenBSD. Хотя, справедливости ради, скажу, что несколько багов (именно багов) было пофиксено позднее. Ну да кто без греха...

>> Правильно. Таблица маршрутизации и фаервол - немного разные инструменты. В вашем случае
>> обе функции ложатся на фаервол. Что вы там говорили про unix
>> way? ;)
> Авторы netfilter позиционируют его не просто как фаервол, а как "фреймворк для
> фильтрации и модификации пакетов". Присвоение пакету тегов - чем не модификация?
> Этот же подход, кстати, справедлив и для pf. Ведь он тоже умеет
> не только блокировать/пропускать пакеты, правда?

Я всего лишь запустил ответную шпильку. ;)

> Кстати, одно занудное замечание: netfilter, в отличие от pf, не имеет возможности
> напрямую вмешаться в процесс маршрутизации. Когда-то существовало патч, вводящий действие
> ROUTE, аналогичное rtable в pf, но его так и не приняли
> в ядро. Логика выбора таблицы реализована в самой системе маршрутизации. netfilter
> может лишь менять теги, являющиеся одним из критериев этой логики. Но
> он не является монополистом в этой области - вот в чем
> весь цимес.

ROUTE, по-моему, скорее соответствовал route-to в PF, которая опция по сути "перекрывает" стандартную маршрутизацию для данного пакета/соединения. Это параллельная доменам маршрутизации фича.

>> Всё то, что вы пока что описываете как фичи netfilter, в PF
>> имеется (что-то давным-давно, что-то не очень). Поэтому реализовать ваш вариант можно
>> и на OpenBSD (да и на FreeBSD как минимум тоже, ipfw
>> местный в последнее время становится всё более человеческим).
> В OpenBSD и FreeBSD приложения могут выставлять для своего трафика теги, которые
> понимает система маршрутизации?

Я уже говорил, что в PF напрямую можно тегировать только его средствами. Это как-то более надёжно, ИМХО, чем позволять приложениям выставлять теги. Что будет, если через взлом одного приложения атакующий получит возможность отправлять трафик от имен доверенного?

С другой стороны, в PF можно динамически добавлять-удалять правила, не мешая друг другу,  недавно даже появилась возможность задания одноразовых правил, которые самоудаляются после первого срабатывания. Можно и напрямую добавлять-удалять стейты. Так что аналогичная функциональность, повторюсь, вполне доступна.

Что до FreeBSD, то вроде бы там ситуация аналогичная, но утверждать это со 100% уверенностью не буду.

>> Но зачем, если есть нормально работающие домены маршрутизации? :)
> Зачем делать гибкое модульное решение, если костыли неплохо подпирают другие костыли?
> Ну, считайте меня перфекционистом :)

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

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

78. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 27-Сен-11, 00:16 
> Для вас домены маршрутизации - это костыли?

В современном, жестком и дубовом их виде - да.

> ROUTE, по-моему, скорее соответствовал route-to в PF

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

>Я уже говорил, что в PF напрямую можно тегировать только его средствами. Это как-то более надёжно, ИМХО, чем позволять приложениям выставлять теги. Что будет, если через взлом одного приложения атакующий получит возможность отправлять трафик от имен доверенного?

В случае с systemd, выставлением тегов занимается процесс init, работающий от рута. Вы полагаете, что в случае исполнения кода в контексте init будет существенной проблемой модифицировать правила фаервола?

>Так что аналогичная функциональность, повторюсь, вполне доступна.

Не вполне понимаю. Не могли бы вы привести пример реализации тегирования пакетов, связанных с заданным сокетом (порт и PID процесса заранее не известны)?

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

Костыль обычно всегда проще прямого решения, поэтому костыли столь популярны.

>Но практичным этот подход назвать никак нельзя.

Да, пусть лучше костыль на костыле сидит и костылем погоняет. Не слушайте старого идеалиста, он бредит.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

80. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 27-Сен-11, 01:41 
>> Для вас домены маршрутизации - это костыли?
> В современном, жестком и дубовом их виде - да.

Дубовом? o_O А мужики-то и не знают. Я-то думал, что когда получается быстрее (пробежаться по таблице роутинга быстрее, чем по правилам фаервола), надёжнее (меньше ручной работы = меньше вероятность ошибки конфигурирования) и проще (каждая задействованная сущность проста доступнее в изучении, чем комплексное решение на фаерволе), то оно лучше, ан вот оно как... :)

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

>>Я уже говорил, что в PF напрямую можно тегировать только его средствами. Это как-то более надёжно, ИМХО, чем позволять приложениям выставлять теги. Что будет, если через взлом одного приложения атакующий получит возможность отправлять трафик от имен доверенного?
> В случае с systemd, выставлением тегов занимается процесс init, работающий от рута.
> Вы полагаете, что в случае исполнения кода в контексте init будет
> существенной проблемой модифицировать правила фаервола?

Гм. systemd использует тегирование пакетов для эмуляции доменов маршрутизации? o_O

Давайте мух отдельно, котлеты отдельно (это я в свете грядущих выборов, ага). Я говорил про ситуацию, когда произвольное приложение (не-рутовое) имеет возможность фактически отправить трафик от имени рутового. Понимаете? Получается, надо всё равно давать возможность фаерволу проверять источник пакета. Что приводит в итоге к, фактически, тегированию силами фаервола.

Кстати, если не секрет, а чего это SO_MARK до сих пор не документирован? Я нашёл было ссылку на багзиллу, датированную ещё 2010-м годом, да вот беда: kernel.org-то до сих пор не реанимирован (полностью)... Может, именно из-за описанных выше причин?

Теперь о systemd и других рутовых процессах. Использование тегов сокета в рутовом приложении ничего не даст для этого приложения с точки зрения безопасности. Но:

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

То есть всё для того, чтобы не было _необходимости_ (не возможности) использовать именно тегирование, по-хорошему уже должно быть. А если нет, то у вас уже есть проблема с угрозой безопасности. И, возможно, не одна.

>>Так что аналогичная функциональность, повторюсь, вполне доступна.
> Не вполне понимаю. Не могли бы вы привести пример реализации тегирования пакетов,
> связанных с заданным сокетом (порт и PID процесса заранее не известны)?

Первый пришедший в голову пример, статика:

match out on <...> user my_daemon_user tag i_want_special_handling

Более сложный, динамика (для понятности даю командами шелла, в Си суть аналогичная):

echo "match from $my_addr port $my_port user $my_daemon_user to $peer_addr port $peer_port once tag i_want_special_handling" | \
pfctl -a myprog/$PPID -f -

Разумеется, вместо tag может быть и любое другое действие, но коли уж говорим о тегировании, то примеры именно с опцией "tag".

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

Господи, ну хотите, считайте костылём, жалко, что ли. :)

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

Да делайте как хотите. Вы же себе жизнь усложняете, а не мне. :)

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

7. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 24-Сен-11, 13:09 
>>Поддержка работы одновременно нескольких экземпляров ntpd(8), что бывает нужно при использовании нескольких доменов маршрутизации;
> Не понял, в чем принципиальная разница нескольких экземпляров ntpd и одного, слушающего
> разные айпишники, с точки зрения маршрутизации?

sshd тоже можно было бы подправить.
Чтобы биндился на каждый интефейс в отдельном домене маршрутизации.
Хотя это можно сделать и самостоятельно.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Сен-11, 13:21 
>>>Поддержка работы одновременно нескольких экземпляров ntpd(8), что бывает нужно при использовании нескольких доменов маршрутизации;
>> Не понял, в чем принципиальная разница нескольких экземпляров ntpd и одного, слушающего
>> разные айпишники, с точки зрения маршрутизации?
> sshd тоже можно было бы подправить.
> Чтобы биндился на каждый интефейс в отдельном домене маршрутизации.
> Хотя это можно сделать и самостоятельно.

Для sshd проблемы нет, одновременная работа нескольких на одном компьютере проблемы не вызывает. Запуск нескольких sshd (и чего угодно вообще) по разным доменам маршрутизации в OpenBSD делается посредством команды "route -T N exec PROGRAM ...", где "N" - номер таблицы маршрутизации.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

19. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от Аноним (??) on 24-Сен-11, 20:05 
Мне кажется, или запуск _программы_ утилитой _маршрутизации_ это довольно криво?

А вот заменить древний как помет мамонта апач на nginx - EPIC WIN, однозначно.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

21. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Сен-11, 20:32 
> Мне кажется, или запуск _программы_ утилитой _маршрутизации_ это довольно криво?

Наоборот, это позволяет избежать необходимости как-либо модифицировать код этих программ. Подобные "лесенки" вызовов - вполне себе unix-way, тот же принцип используется для env и sudo, например.

И чем вам утилита маршрутизации - не программа? :) С другой стороны, утилита маршрутизации настраивает маршрутизацию - тоже логично, не?

Если кому-то надо интенсивно стартовать какой-то софт в разных доменах маршрутизации - что ж, тогда можно и в стартующей программе setrtable(2) делать перед exec(2). Но это уже сверхоптимизация, для запуска системных сервисов как-то не особо актуальная.

Впрочем, если у вас есть лучшее (более гибкое и надёжное) решение, так же не требующее всего софта подряд (sic!) - вас внимательно слушают. :)

> А вот заменить древний как помет мамонта апач на nginx - EPIC
> WIN, однозначно.

Основная (не единственная, но основная) причина замены - не "древность" (сколько лет утилите cp? ;) ), а смерть апстрима. Апач в Опёнке, конечно, поддерживали: исправляли проблемы с надёжностью вообще и безопасностью в частности, добавляли какие-то фичи - но каждый год всё больше сил на это уходило. Об nginx, как о подходящей и с технической, и с лицензионной точки зрения замене, речь заходила ещё несколько лет назад; сейчас уже не вспомню, что поначалу служило стопором.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

36. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  –2 +/
Сообщение от Аноним (??) on 25-Сен-11, 23:18 
> Наоборот, это позволяет избежать необходимости как-либо модифицировать код этих программ.

Это такое закамуфлированное оправдание - мол, свое - не пахнет?
Такой подход - как минимум брутальное покладание на юникс вэй вообще, когда программа делает _одну_ вещь и делает ее хорошо (с хрена ли утилита роутинга вообще что-то запускает? Она управлятор роутингом а не запускач!) и на здравый смысл в частности (запуск программ утилитой роутинга - это же так очевидно).

> Подобные "лесенки" вызовов - вполне себе unix-way, тот же принцип используется для env и sudo, например.

Есть небольшое отличие: sudo как бы создан для запуска других программ. Чтобы sudo сравнивать с таким маразмом, надо научить его прописывать что-нибудь в роутинговые таблицы. А чем он хуже то? Если route'у можно запускать программы, тогда sudo'у не зазорно в таблицу роутинга слазить.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

37. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 02:18 
>> Наоборот, это позволяет избежать необходимости как-либо модифицировать код этих программ.
> Это такое закамуфлированное оправдание - мол, свое - не пахнет?

Это чистой воды прагматизм. Или благородный дон предлагает переписывать ВЕСЬ взаимодействующий с сетью софт, который только может запускаться в системе? Вы этот момент упорно не замечаете.

> Такой подход - как минимум брутальное покладание на юникс вэй вообще, когда
> программа делает _одну_ вещь и делает ее хорошо (с хрена ли
> утилита роутинга вообще что-то запускает? Она управлятор роутингом а не запускач!)

Она управляет роутингом - в отдельно взятой программе.

> и на здравый смысл в частности (запуск программ утилитой роутинга -
> это же так очевидно).

Это освещено в документации. Которой OpenBSD небезосновательно гордится.

>> Подобные "лесенки" вызовов - вполне себе unix-way, тот же принцип используется для env и sudo, например.
> Есть небольшое отличие: sudo как бы создан для запуска других программ. Чтобы
> sudo сравнивать с таким маразмом, надо научить его прописывать что-нибудь в
> роутинговые таблицы. А чем он хуже то? Если route'у можно запускать
> программы, тогда sudo'у не зазорно в таблицу роутинга слазить.

Если начинать с того, что для чего было создано, так и Linux был just for fun.

Опять-таки, конструктивных предложений с вашей стороны не видно (мои слова об этом вы скромно порезали из цитаты). Троллите плохо. Счастливо оставаться.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

40. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +3 +/
Сообщение от kibab email on 26-Сен-11, 10:15 
Мне кажется, для таких ребят в базовой системе надо иметь программу setfib как жёсткую ссылку на route, тогда они успокоятся и не будут орать про нарушение принципа unix-way, не особо понимая при этом суть этого самого unix-way :-)
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

50. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 26-Сен-11, 17:48 
> Это освещено в документации. Которой OpenBSD небезосновательно гордится.

В каком месте документации представлены доказательства
слов "proactively secure"? Хотелось бы увидеть полный список
вещей, посвященных безопасности.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

51. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 17:55 
На больное место давите? ;)
Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

54. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 26-Сен-11, 18:07 
> На больное место давите? ;)

На самом деле нет. Я не такой злобный. Просто хочу ставнить с

http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
http://mail-index.netbsd.org/tech-kern/2011/07/10/msg010913.... (внизу)

и grsecurity (частично, до чего руки дотянулись)

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

55. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 26-Сен-11, 18:22 
>> На больное место давите? ;)
> На самом деле нет. Я не такой злобный. Просто хочу ставнить с
> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
> http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
> http://mail-index.netbsd.org/tech-kern/2011/07/10/msg010913.... (внизу)
> и grsecurity (частично, до чего руки дотянулись)

Ну и capsicum до кучи

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

56. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 18:29 
> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
> http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
> http://mail-index.netbsd.org/tech-kern/2011/07/10/msg010913.... (внизу)

Солидно. Верной дорогой идут товарищи. Разве что kauth увлеклись, а из документированных защит ядра реализовали только запрет на маппинги по нулевому адресу.

На сколько я знаю, документации по механизмам защиты в OpenBSD нет.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

57. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 26-Сен-11, 18:49 
>> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
>> http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
>> http://mail-index.netbsd.org/tech-kern/2011/07/10/msg010913.... (внизу)
> Солидно. Верной дорогой идут товарищи. Разве что kauth увлеклись,

Как раз здесь кое-чего и не хватает IMHO.

> а из документированных
> защит ядра реализовали только запрет на маппинги по нулевому адресу.

Не понял.

> На сколько я знаю, документации по механизмам защиты в OpenBSD нет.

Если даже реализованное нигде толком не описано, тогда к чему
весь этот proactive бред? Ради чего производительность на SMP
машинах принесена в жертву?

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

61. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 20:04 
> Как раз здесь кое-чего и не хватает IMHO.

Да, но начало хорошее.

>> а из документированных
>> защит ядра реализовали только запрет на маппинги по нулевому адресу.
> Не понял.

Они реализовали только защиту от одного из распространённых подклассов уязвимостей - NULL pointer dereference. Защит от других классов и способов эксплуатации пока нет.

> Если даже реализованное нигде толком не описано, тогда к чему
> весь этот proactive бред? Ради чего производительность на SMP
> машинах принесена в жертву?

SMP ни при чём. Почему документации нет, я тоже не понимаю.

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

63. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 26-Сен-11, 20:27 
>>> а из документированных
>>> защит ядра реализовали только запрет на маппинги по нулевому адресу.
>> Не понял.
> Они реализовали только защиту от одного из распространённых подклассов уязвимостей - NULL
> pointer dereference. Защит от других классов и способов эксплуатации пока нет.

Я не понимаю, кто они. NetBSD или OpenBSD?
Если первое, то хотелось бы глянуть на список остальных
в более-менее популярном изложении. В моем понимании
SSP, например, касается защиты ядра самым непосредственным образом.

>> Если даже реализованное нигде толком не описано, тогда к чему
>> весь этот proactive бред? Ради чего производительность на SMP
>> машинах принесена в жертву?
> SMP ни при чём. Почему документации нет, я тоже не понимаю.

В OpenBSD сознательно забили на проблему giant lock и производительности на SMP
якобы в пользу безопасности. И вот мне непонятно, ради чего конкретно.
Перерезус что-то молчит. Еще OpenBSD-шники волочат systrace, признанный
дырявым by design. Видимо, ввиду особенностей реализации у них SMP,
дыры подхода sysstrace не проявляются. Ну или это просто чудовищный недосмотр.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

65. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от коксюзер on 26-Сен-11, 21:01 
> Я не понимаю, кто они. NetBSD или OpenBSD?

NetBSD. Впрочем, OpenBSD тоже (если только что-то не изменилось за последние полгода).

> Если первое, то хотелось бы глянуть на список остальных
> в более-менее популярном изложении. В моем понимании
> SSP, например, касается защиты ядра самым непосредственным образом.

Да, про SSP я забыл. Но все признанные эксперты, с кем мне приходилось общаться, не считают SSP существенной мерой, особенно при отсутствии ядерного аналога KERNEXEC (W^X).

> В OpenBSD сознательно забили на проблему giant lock и производительности на SMP  
> якобы в пользу безопасности. И вот мне непонятно, ради чего конкретно.

Если не ошибаюсь, всё-таки в пользу надёжности и простоты реализации. Не осилили, я бы сказал. :) Даже PAE не осилили, чего уж там.

> Перерезус что-то молчит. Еще OpenBSD-шники волочат systrace, признанный
> дырявым by design. Видимо, ввиду особенностей реализации у них SMP,

By design он убогий. Дырявый он by implementation именно в OpenBSD. Они до сих пор не осилили буферизацию аргументов, передаваемых в сисколлы по указателям, хотя сделать это надо было изначально. Но Provos ушёл из проекта, осиливать некому.

> дыры подхода sysstrace не проявляются. Ну или это просто чудовищный недосмотр.

Проявляются-проявляются, даже в man'е описаны (секция BUGS):
http://www.openbsd.org/cgi-bin/man.cgi?query=systrace&apropo...

Кстати, clone()-like - это fork. Но чтобы понять, что за clone() такой, нужно знать о происхождении systrace из линукса и найти документацию по clone(2). Качество документаци на высоте. ;) Кстати, о документации: с CARP ситуация ещё хуже - его описания нет до сих пор. Учитывая, что в нём применяется криптография для защиты от некоторых угроз, отсутствие документации в очередной раз, конечно, упрощает peer review как этих аспектов, так и протокола в целом. ;)

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

69. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 21:34 
>> Если первое, то хотелось бы глянуть на список остальных
>> в более-менее популярном изложении. В моем понимании
>> SSP, например, касается защиты ядра самым непосредственным образом.
> Да, про SSP я забыл. Но все признанные эксперты, с кем мне
> приходилось общаться, не считают SSP существенной мерой, особенно при отсутствии ядерного
> аналога KERNEXEC (W^X).

Насколько помню, в OpenBSD W^X есть и в ядре, если не забуду - уточню позже. Может, действительно нужен список защитных механизмов?.. :)

>> В OpenBSD сознательно забили на проблему giant lock и производительности на SMP
>> якобы в пользу безопасности. И вот мне непонятно, ради чего конкретно.
> Если не ошибаюсь, всё-таки в пользу надёжности и простоты реализации. Не осилили,
> я бы сказал. :) Даже PAE не осилили, чего уж там.

Поддержка PAE некоторое время имелась, но потом была выпилена как бесполезная в век 64-битных процессоров.

>> Перерезус что-то молчит. Еще OpenBSD-шники волочат systrace, признанный
>> дырявым by design. Видимо, ввиду особенностей реализации у них SMP,
> By design он убогий. Дырявый он by implementation именно в OpenBSD. Они
> до сих пор не осилили буферизацию аргументов, передаваемых в сисколлы по
> указателям, хотя сделать это надо было изначально. Но Provos ушёл из
> проекта, осиливать некому.

Насколько помню, там не всё так просто, "честный" способ заметно снизит производительность. Что сделает systrace действительно бесполезным. А то где-то есть пример "починенного" systrace? Я бы глянул.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

70. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 21:48 
> Насколько помню, в OpenBSD W^X есть и в ядре, если не забуду
> - уточню позже. Может, действительно нужен список защитных механизмов?.. :)

Уточните, пожалуйста.

> Поддержка PAE некоторое время имелась, но потом была выпилена как бесполезная в
> век 64-битных процессоров.

Надо же! Значит, я не застал.

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

Возможно. В детали реализации я не углублялся, но в других системах таких проблем нет. Например, в Grsecurity RBAC.

> Что сделает systrace действительно бесполезным. А то где-то есть пример "починенного"
> systrace? Я бы глянул.

http://www.systrace.org - пример несломанного. ;)

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

82. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 27-Сен-11, 03:24 
>> Насколько помню, в OpenBSD W^X есть и в ядре, если не забуду
>> - уточню позже. Может, действительно нужен список защитных механизмов?.. :)
> Уточните, пожалуйста.

Посмотрел. Ничего похожего, на самозащиту ядра в виде W^X не нашёл (по крайней мере в MI- и i386-коде). Правда, чем больше искал, тем больше понимал, что не уверен в том, что ищу то же самое, о чём говорите вы. :) Вы имели в виду, что если ядро в какую-то страницу памяти что-то пишет, то потом оно же эту страницу памяти не будет выполнять? Если говорить о страницах, которые мапятся в юзерленд, то эта проблема уже решена. Если говорить о страницах, где выполняться может само ядро, то такая ситуация в принципе невозможна (при условии корректной работы подсистемы выделения памяти, разумеется, но если в этой подсистеме есть ошибки, то говорить о какой-либо защите бессмысленно изначально). Ну или я не вижу за деревом леса...

>> Насколько помню, там не всё так просто, "честный" способ заметно снизит производительность.
> Возможно. В детали реализации я не углублялся, но в других системах таких
> проблем нет. Например, в Grsecurity RBAC.

Надо будет ещё раз поглядеть в код опёнковского systrace. Вдруг чего и получится починить... GrSecurity хорош, не спорю, но в данном случае, как вы понимаете, немного мимо. :)

> http://www.systrace.org - пример несломанного. ;)

Гм. Это ж только userland-часть. Так-то systrace(1) и в Опёнке не "сломанный". А проблема-то связана с копированием аргументов в ядро и далее...

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

85. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 27-Сен-11, 05:28 
> Посмотрел. Ничего похожего, на самозащиту ядра в виде W^X не нашёл (по
> крайней мере в MI- и i386-коде). Правда, чем больше искал, тем

Вы лучше спросите. А то все ищут, никто не находит, а вопрос повис.

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

Ядро не должно иметь доступ на выполнение страниц, в которые оно имеет доступ на запись. Не только своих, кстати, но и пользовательских. На x86 это достижимо, на amd64 - достижимо с оговорками.

> которые мапятся в юзерленд, то эта проблема уже решена. Если говорить
> о страницах, где выполняться может само ядро, то такая ситуация в
> принципе невозможна (при условии корректной работы подсистемы выделения памяти, разумеется,

Не понял, какую именно ситуацию вы имели ввиду.

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

Ошибки могут быть и есть везде, совершенство недостижимо, но это не повод опускать руки.

> Надо будет ещё раз поглядеть в код опёнковского systrace. Вдруг чего и
> получится починить... GrSecurity хорош, не спорю, но в данном случае, как
> вы понимаете, немного мимо. :)

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

> Гм. Это ж только userland-часть. Так-то systrace(1) и в Опёнке не "сломанный".
> А проблема-то связана с копированием аргументов в ядро и далее...

Там ссылка в README на патч для ядра:
http://www.citi.umich.edu/u/provos/systrace/linux.html

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

87. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 27-Сен-11, 12:42 
> Может, действительно нужен список защитных механизмов?.. :)

Да-да, хотя бы для того, чтобы хвастаться в следующий раз качеством документации
OpenBSD ;-) Вот я, например, показал, что конкретно сделано для параноиков
в NetBSD, просто дав ссылку на пару манов и пример использования kauth(9).
OpenBSD-шники же просто машут руками и кормят всех словами.
Да и древняя байка "OpenBSD - безопастно, NetBSD - портабельно,
FreeBSD - быстро", в которую многие до сих пор верят, мне лично осточертела.
К реальности она не имеет ни малейшего отношения.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

109. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 05:08 
>> Может, действительно нужен список защитных механизмов?.. :)
> Да-да, хотя бы для того, чтобы хвастаться в следующий раз качеством документации
> OpenBSD ;-) Вот я, например, показал, что конкретно сделано для параноиков
> в NetBSD, просто дав ссылку на пару манов и пример использования kauth(9).

Так насколько я понимаю, там тоже не всё перечислено? Или всё? :)

> OpenBSD-шники же просто машут руками и кормят всех словами.
> Да и древняя байка "OpenBSD - безопастно, NetBSD - портабельно,
> FreeBSD - быстро", в которую многие до сих пор верят, мне лично
> осточертела.
> К реальности она не имеет ни малейшего отношения.

От таких "баек" никуда не деться. Склонность человеческой натуры - упрощать непонятное. :)

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

115. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle (ok) on 28-Сен-11, 10:01 
>>> Может, действительно нужен список защитных механизмов?.. :)
>> Да-да, хотя бы для того, чтобы хвастаться в следующий раз качеством документации
>> OpenBSD ;-) Вот я, например, показал, что конкретно сделано для параноиков
>> в NetBSD, просто дав ссылку на пару манов и пример использования kauth(9).
> Так насколько я понимаю, там тоже не всё перечислено? Или всё? :)

Ну, не совсем все. Например о том, что NetBSD - единственная система, где
залатаны дыры в chroot-е (для непривилегированного пользователя, конечно)
там ничего не сказано. Об этом в [f]chroot(2), fchdir(2), ptrace(2) и др.
В OpenBSD chroot дырявый, как и у всех прочих.

Есть еще частные маны вроде
http://netbsd.gw.com/cgi-bin/man-cgi?secmodel_securelevel+9+...

>> OpenBSD-шники же просто машут руками и кормят всех словами.
>> Да и древняя байка "OpenBSD - безопастно, NetBSD - портабельно,
>> FreeBSD - быстро", в которую многие до сих пор верят, мне лично
>> осточертела.
>> К реальности она не имеет ни малейшего отношения.
> От таких "баек" никуда не деться. Склонность человеческой натуры - упрощать непонятное.
> :)

OpenBSD-шникам байка про них, похоже, нравится ;-)

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

117. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от guest email(??) on 28-Сен-11, 12:30 
>Ну, не совсем все. Например о том, что NetBSD - единственная система, где
>залатаны дыры в chroot-е (для непривилегированного пользователя, конечно)
>там ничего не сказано. Об этом в [f]chroot(2), fchdir(2), ptrace(2) и др.
>В OpenBSD chroot дырявый, как и у всех прочих.

Вот не поленился, прочитал их man - единственное упомянутое отличие от прочих систем интегрированный chdir(). На мой взгляд сомнительная ценность... а уж к безопасности не имеет никакого отношения.
Единственное, что можно сделать с chroot() в плане безопасности это разрешить его использовать 1 раз, но в манах NetBSD про это не слова.

Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

120. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 28-Сен-11, 13:05 
>>Ну, не совсем все. Например о том, что NetBSD - единственная система, где
>>залатаны дыры в chroot-е (для непривилегированного пользователя, конечно)
>>там ничего не сказано. Об этом в [f]chroot(2), fchdir(2), ptrace(2) и др.
>>В OpenBSD chroot дырявый, как и у всех прочих.
> Вот не поленился, прочитал их man - единственное упомянутое отличие от прочих
> систем интегрированный chdir(). На мой взгляд сомнительная ценность... а уж к
> безопасности не имеет никакого отношения.

fchdir(2):
     fchdir() will fail and the current working directory will be unchanged if
     one or more of the following are true:
     ...
     [EPERM]            The argument fd references a directory which is not at
                        or below the current process's root directory.

Из chroot-а этим способом нельзя. В OpenBSD, Linux, FreeBSD... можно.

ptrace смотри сам.

> Единственное, что можно сделать с chroot() в плане безопасности это разрешить его
> использовать 1 раз, но в манах NetBSD про это не слова.

chroot(2) разрешен только для root-а. А если у тебя root, у тебя 1000+1 способ
сделать все, чего тебе захочется. См. handened chroot у grsecurity
или по ссылке, что я давал, на аналогичный securechroot для NetBSD.

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

121. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от guest email(??) on 28-Сен-11, 13:29 
> Из chroot-а этим способом нельзя. В OpenBSD, Linux, FreeBSD... можно.

Так при этом
fd=open("/");
chroot("/foo");
fchroot(fd);
прекрасно отработает (я не проверял за неимением, но если верить man должно)

> сделать все, чего тебе захочется. См. handened chroot у grsecurity
> или по ссылке, что я давал, на аналогичный securechroot для NetBSD.

На сколько я помню, там как раз не дают делать chroot из chroot'а вообще.
А в таком виде как в NetBSD, я б назвал это полумерой.

Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

122. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 28-Сен-11, 14:23 
>> Из chroot-а этим способом нельзя. В OpenBSD, Linux, FreeBSD... можно.
> Так при этом
> fd=open("/");
> chroot("/foo");
> fchroot(fd);
> прекрасно отработает (я не проверял за неимением, но если верить man должно)

work# cat fchdir.c
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int main ()
{
        int ret;
        int fd = open ("/", O_RDONLY | O_DIRECTORY);

        if (fd == -1){
                perror ("open(2) failed");
                return 1;
        }

        if (chroot ("/tmp") == -1){
                perror ("chroot(2) failed");
                return 1;
        }

        if (chdir ("/") == -1){
                perror ("chdir(2) failed");
                return 1;
        }

        if (fchdir (fd) == -1){
                perror ("fchdir(2) failed");
                return 1;
        }

        ret = system ("ls .");
        if (ret == -1){
                perror ("system(3) failed");
                return 1;
        }

        return ret;
}
work# cc fchdir.c  
work# ./a.out                                                                            
fchdir(2) failed: Operation not permitted
work# uname -srm
NetBSD 5.99.53 i386
work#

>> сделать все, чего тебе захочется. См. handened chroot у grsecurity
>> или по ссылке, что я давал, на аналогичный securechroot для NetBSD.
> На сколько я помню, там как раз не дают делать chroot из
> chroot'а вообще.

Где там? И в grsecurity и в securechroot он не разрешен совсем.

> А в таком виде как в NetBSD, я б назвал это полумерой.

В таком виде NetBSD-ый chroot вполне подходит как основа для нормально
hardened chroot-а a la тому, что сделано в grsecurity. Собственно его я и сделал
для NetBSD по образу и подобию,
и он пригоден для изоляции в загончике даже root-а.
На все ~800 строк кода поверх kauth(9), включая man page.

Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

123. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от guest email(??) on 28-Сен-11, 14:35 
> work# cat fchdir.c

...
>         if (fchdir (fd) == -1){

Я вам верю, что fchdir() работает как написано в man. Но посмотрите внимательно:
fd=open("/");
chroot("/foo");
fchroot(fd);

> Где там? И в grsecurity и в securechroot он не разрешен совсем.

Ну я вот смотрю в список фичей grsecurity и вижу там опцию "Deny double-chroots"...

Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

124. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 28-Сен-11, 14:53 
>> work# cat fchdir.c
> ...
>>         if (fchdir (fd) == -1){
> Я вам верю, что fchdir() работает как написано в man. Но посмотрите
> внимательно:
> fd=open("/");
> chroot("/foo");
> fchroot(fd);

Про fchroot я уже ответил. Он требует root-а.
Защищать fchroot при условии, что root-у возможен, скажем, mknod(2)
не имеет ни малейшего смысла.

>> Где там? И в grsecurity и в securechroot он не разрешен совсем.
> Ну я вот смотрю в список фичей grsecurity и вижу там опцию
> "Deny double-chroots"...

Это я знаю, именно из этого списка я брал основные идеи для securechroot.
http://mail-index.netbsd.org/tech-kern/2011/07/10/msg010913.... (внизу)
Список "фич" легко сравнить.

Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

125. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от guest email(??) on 28-Сен-11, 15:25 
> Про fchroot я уже ответил. Он требует root-а.
> Защищать fchroot при условии, что root-у возможен, скажем, mknod(2)
> не имеет ни малейшего смысла.

Дошло, спасибо.

> http://mail-index.netbsd.org/tech-kern/2011/07/10/msg010913.... (внизу)
> Список "фич" легко сравнить.

Здорово. Единственное значимое отличие которое заметил - shmat()

Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

126. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 17:35 
>[оверквотинг удален]
>>> OpenBSD ;-) Вот я, например, показал, что конкретно сделано для параноиков
>>> в NetBSD, просто дав ссылку на пару манов и пример использования kauth(9).
>> Так насколько я понимаю, там тоже не всё перечислено? Или всё? :)
> Ну, не совсем все. Например о том, что NetBSD - единственная система,
> где
> залатаны дыры в chroot-е (для непривилегированного пользователя, конечно)
> там ничего не сказано. Об этом в [f]chroot(2), fchdir(2), ptrace(2) и др.
> В OpenBSD chroot дырявый, как и у всех прочих.
> Есть еще частные маны вроде
> http://netbsd.gw.com/cgi-bin/man-cgi?secmodel_securelevel+9+...

Ну вот и получается, что не всё в одном месте. ;) securelevel(7) и в OpenBSD есть...

>>> OpenBSD-шники же просто машут руками и кормят всех словами.
>>> Да и древняя байка "OpenBSD - безопастно, NetBSD - портабельно,
>>> FreeBSD - быстро", в которую многие до сих пор верят, мне лично
>>> осточертела.
>>> К реальности она не имеет ни малейшего отношения.
>> От таких "баек" никуда не деться. Склонность человеческой натуры - упрощать непонятное.
>> :)
> OpenBSD-шникам байка про них, похоже, нравится ;-)

Те же байки говорят, например, что OpenBSD нельзя использовать на десктопе. Даже когда тычешь носом таких вот какашкометателей в серийное применение Опёнка в качестве домашнего или рабочего десктопа, говорят: "это потому что они там все идиоты".

А объяснять, что безопасность обеспечивается процессом, а не инструментами, обычно попросту бесполезно...

P.S.: Прошу прощения, что не на все сообщения в теме вовремя отвечаю, банально не успеваю.

Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

127. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 28-Сен-11, 18:26 
>> Есть еще частные маны вроде
>> http://netbsd.gw.com/cgi-bin/man-cgi?secmodel_securelevel+9+...
> Ну вот и получается, что не всё в одном месте. ;) securelevel(7)
> и в OpenBSD есть...

На secmodel_securelevel(9) есть ссылка из security(7).
AFAIK security(7) в NetBSD не задумывался, как единое место, где было бы описано
всё, касающееся безопасности. Он просто таким получился, и он вполне подробный,
позволяющий получить представление о подходе разработчиков к этой проблеме.
Про OpenBSD я уже сказал. Нет даже списка фич -> невозможно сравнить
с конкурентами -> невозможен независимый review -> нет повода верить навязчивой
рекламе и бахвальству. ЧТД. Нет, может она и неплоха, но документации нет.

>> OpenBSD-шникам байка про них, похоже, нравится ;-)
> Те же байки говорят, например, что OpenBSD нельзя использовать на десктопе.

И в каком состоянии в OpenBSD драйвера для видеокарт Intel, ATI, NVidia?
GEM/KMS уже работают? VAAPI? VDPAU? Нет, NetBSD в этом смысле похвастаться
абсолютно нечем. Что-то мне подсказывает, что во всех *BSD
пока еще куча проблем в этом месте. Не далее как в эту субботу Белоусов расказывал
о статусе GEM/KMS во FreeBSD на KievBSD. Очень краткое резюме: работы еще Гора.
В OpenBSD лучше?

Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

128. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 29-Сен-11, 01:55 
>>> OpenBSD-шникам байка про них, похоже, нравится ;-)
>> Те же байки говорят, например, что OpenBSD нельзя использовать на десктопе.
> И в каком состоянии в OpenBSD драйвера для видеокарт Intel, ATI, NVidia?

Intel: Работает, включая 3D. Сейчас отлаживают полноценную поддержку Sandy Bridge (в 5.0 оно работает, но что-то там из фич - не вникал в детали - не включено).

ATI: Работает; AFAIK, с DRM на некоторых чипсетах есть проблемы, но по крайней мере дома на десктопе пашет.

NVIDIA: Не помню, выпилен ли nv(4), но радостных моментов нет.

> GEM/KMS уже работают?

GEM: http://mail-index.netbsd.org/current-users/2011/02/08/msg015... ;)

KMS: допиливают, есть шансы, что появится в 5.1.

> VAAPI? VDPAU?

AFAIK, нет. Правда, редко этими труднозапоминаемыми модными буквосочетаниями интересуюсь. :) Второе, кажется, вообще только про NVIDIA?

> Нет, NetBSD в этом смысле похвастаться
> абсолютно нечем. Что-то мне подсказывает, что во всех *BSD
> пока еще куча проблем в этом месте. Не далее как в эту
> субботу Белоусов расказывал
> о статусе GEM/KMS во FreeBSD на KievBSD. Очень краткое резюме: работы еще
> Гора.
> В OpenBSD лучше?

По видео выше. Звук поддерживается хорошо, плюс фреймворк sndio(7) интегрирован прямо или косвенно практически во все порты, от XMMS до свежепортированного PulseAudio. Всякие там хитрые тачпады поддерживаются. Wi-Fi работает, правда, нет поддержки 802.11n. Firewire нет. Bluetooth есть, хотя поддержка не фонтан: первоначально его портировали как раз из NetBSD, но давно не синхронизировали поддержку, в общем, код протухает; по крайней мере в инет вылезти можно. Win-модемы не поддерживаются как класс. Псевдорейды от всяких там Интелей по факту не поддерживаются, хотя это лишь вопрос небольшого приложения энтузиазма: в softraid(4) изначально предусмотрена поддержка сторонних форматов метаданных. USB3-чипсеты опознаются и работают, но поддержка не полная. ACPI работает довольно хорошо (собственная реализация).

Системное ПО: Есть и поддерживаются все основные DE (исключение - KDE 4 протух, работаем над этим). UDev не портирован/эмулирован, поэтому завязанный на него функционал по большей части не пашет (есть родные аналогичные средства, типа hotplug(4)/hotplugd(8); надеюсь, у меня хватит терпения заставить KDE слиться с ними в экстазе). FUSE (который про файловые системы) и Wine не пашут; портирование последнего несколько раз начиналось, но так и не было доведено до конца. Как следствие, NTFS доступна только для чтения. NFS и Kerberos в базовой системе. Samba в портах. OpenAFS частично там, частично сям.

Современные браузеры, почтовые клиенты, мессенджеры, качалки и прочие интернет-приблуды имеются. Из популярных офисных пакетов не портирован, AFAIK, только KOffice (см. выше про KDE 4). Skype вроде как работает под Linux ABI, не проверял. Для видео использую MPlayer и VLC, последний в последнее время чаще - на взгляд он плавнее видео воспроизводит. Для звука Clementine (тоже в процессе портирования, у него какой-то неясный баг с большими каталогами, в остальном работает), в консоли - sox. Flash через Gnash: видеоролики частично работают, остальное вытаскиваю плагином к FireFox или консольной утилитой yt (для YouTube).

Ещё недавно использовал KDE 3.5 и amaroK 1.4 без каких-либо заметных проблем. Жена по-прежнему сидит в KDE 3.5, главные приложения - chromium, digiKam и Kopete. Первый, конечно, жрёт память как напичканный солитёрами, но работает исправно. Диски записываю через K3b, никаких проблем; диск в нём я запорол всего раз на моей памяти, как-то уж совсем сильно перезгрузив систему во время прожига.

Так что GNOME-, Xfce- и KDE3-десктопы на OpenBSD сейчас вполне юзабельны. Первые два активно поддерживаются французской командой в актуальном состоянии, но я лично с ними (гномами и их друзьями) так и не подружился. :) Сам сейчас сижу обычно в CWM - после "современных" оконных менеджеров он кажется глотком свежего воздуха; правда, KDE у меня сейчас по понятным причинам собран в отладочной версии - может, в релизной конфигурации KWin будет порезвее.

Иными словами: вконтактик открывается, киношки показываются, фотки заливаются, даже поКвакать можно на досуге (конечно, Chroma - наше всё, но иногда думать становится слишком больно :) ). Для корпоративщиков есть стабильно работающий механизм обновлений, всякоразные Nagios'ы и Puppet'ы, поддерка различных платформ и языков программирования - от Mono до оберонов, современные СУБД... Разве что Oracle Database проблематично запинать (пробовал 10g под Linux ABI поставить, и чего-то там ему не понравилось).

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

131. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 29-Сен-11, 12:47 
> Intel: Работает, включая 3D. Сейчас отлаживают полноценную поддержку Sandy Bridge (в 5.0
> оно работает, но что-то там из фич - не вникал в
> детали - не включено).

Замечательно.

> ATI: Работает; AFAIK, с DRM на некоторых чипсетах есть проблемы, но по
> крайней мере дома на десктопе пашет.

Ну, десктоп дома на статистику не тянет. Нужен какой-то более менее
нормальный обзор.

> NVIDIA: Не помню, выпилен ли nv(4), но радостных моментов нет.
>> GEM/KMS уже работают?
> GEM: http://mail-index.netbsd.org/current-users/2011/02/08/msg015... ;)

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

> KMS: допиливают, есть шансы, что появится в 5.1.

Печаль в том, что у меня дома стоит два NIVidia-based nettop-а.
И Net/OpenBSD не может использовать видеокарты по полной программе,
т.е. хотя бы с 1080p/vdpau. В игрушки я не играю. Для Free есть
проприетарный драйвер. nouveau(4), как я понимаю, тоже не работает на OpenBSD.

Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

67. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 21:18 
>>> Если даже реализованное нигде толком не описано, тогда к чему
>>> весь этот proactive бред? Ради чего производительность на SMP
>>> машинах принесена в жертву?
>> SMP ни при чём. Почему документации нет, я тоже не понимаю.
> В OpenBSD сознательно забили на проблему giant lock и производительности на SMP
> якобы в пользу безопасности.

o_O Надёжности - да (что, в принципе, конечно, отчасти связано с безопасностью). Сырое решение никто выкатывать не будет, а сил разработчиков не настолько много, чтобы всё и сразу.

Вообще параллелизация работы включает в себя:

- Параллельную работу userland-кода - это главное и это есть;
- Параллельную работу с ядром из нескольких процессов - мешает giant lock;
- Параллельную работу ядра с устройствами, в частности, распределение сетевого стека по разным процессорам - ядро движется к fine-grained locking, но пока что не более того;
- Существование потоков выполнения внутри процесса как самостоятельных единиц, способных выполняться на разных процессорах одновременно - есть librthread как альтернатива дефолтной libpthread: пока ещё не вылизано, но при желании можно экспериментировать; у меня с ней, например, не завёлся VLC, а вот некая задача с интенсивным I/O и потоками в Perl отрабатывала на ура.

> И вот мне непонятно, ради чего конкретно. Перерезус что-то молчит.

Ради всего остального. :-P На проблемы эти не забили, решают как могут, стараясь не испортить своими наработками что-то ещё. Помните, сколько вою было по выходу FreeBSD 5? Не хотелось бы повторить. :)

> Еще OpenBSD-шники волочат systrace, признанный дырявым by design.
> Видимо, ввиду особенностей реализации у них SMP, дыры подхода sysstrace не проявляются.

Проявляются как у всех. Вы почитайте поподробнее об уязвимости, для её использования достаточно любых двух потоков выполнения в одном процессе, "честных" или нет.

> Ну или это просто чудовищный недосмотр.

systrace используется, например, при сборке пакетов. Чтобы отлавливать кривые конфигураторы-инсталляторы, лезущие за пределы рабочего каталога. Для тех, кто занимается портами, официальная рекомендация - использовать флаг USE_SYSTRACE=Yes в /etc/mk.conf.

Да и в sysjail (не часть базовой системы, но всё же), думаю, всё ещё запустить что-то мирное вполне можно, поэкспериментировать.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

68. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 21:29 
> Проявляются как у всех. Вы почитайте поподробнее об уязвимости, для её использования

Не вводите в заблуждение. Ни у кого таких гонок нет и не было.

> достаточно любых двух потоков выполнения в одном процессе, "честных" или нет.

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

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

71. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 22:12 
>> Проявляются как у всех. Вы почитайте поподробнее об уязвимости, для её использования
> Не вводите в заблуждение. Ни у кого таких гонок нет и не
> было.

Гм?

>> достаточно любых двух потоков выполнения в одном процессе, "честных" или нет.
> Нет, именно "честных". "Нечестный" поток не сможет получить управление, пока его процесс
> находится в контексте ядра.

Кстати да, чего-то я ступил. Зато другой процесс сможет, посредством механизмов типа shared memory...

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

75. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 23:22 
> Гм?

Я имел ввиду, что ни у кого не было таких race conditions с временным окном для перезаписи аргументов после их проверки системой контроля. Но я таки припоминаю, что лет 8 назад гонки всё-же были. Не помню только, где именно.


Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

94. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 27-Сен-11, 15:43 
> - Параллельную работу userland-кода - это главное и это есть;
> - Параллельную работу с ядром из нескольких процессов - мешает giant lock;
> - Параллельную работу ядра с устройствами, в частности,

По-моему тут набор взаимоисключающих параграфов написан. Первое - главное? Только для чисто вычислительных задач (CPU-bound нежели I/O bound). Ну да, крякеры мд5 на скорость тормзить не будут. А вот I/O bound программы (столь типичные для серверов) будут часто стоять колом ожидая у моря погоды при такой "многопроцессорности".

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

101. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 01:01 
>> - Параллельную работу userland-кода - это главное и это есть;
>> - Параллельную работу с ядром из нескольких процессов - мешает giant lock;
>> - Параллельную работу ядра с устройствами, в частности,
> По-моему тут набор взаимоисключающих параграфов написан. Первое - главное? Только для чисто
> вычислительных задач (CPU-bound нежели I/O bound). Ну да, крякеры мд5 на
> скорость тормзить не будут. А вот I/O bound программы (столь типичные
> для серверов) будут часто стоять колом ожидая у моря погоды при
> такой "многопроцессорности".

Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый ввод-вывод будет всё равно упираться в не успевающую его прожёвывать программу. Единственное исключение - ситуации, когда ввод-вывод полностью или практически полностью обрабатывается ядром: та же маршрутизация сетевых пакетов, например (т.е. сквозь машину, а не к ней или от неё). Почти все задачи практического применения - либо в первую очередь нагружают вычислительные мощности, либо нагружают всё подряд. Так что параллельная работа userland-кода всё-таки важнее: для десктопа, для web-сервера, для СУБД... Вот, скажем, почтовый релей или распределённая лёгковесная СУБД, например, уже может при определённых условиях упереться в ввод-вывод, да. Но и в них большая часть работы идёт в userland'е.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

118. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Michael Shigorin email(ok) on 28-Сен-11, 12:42 
> Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый
> ввод-вывод будет всё равно упираться в не успевающую его прожёвывать программу.

Если не будет возможности распараллелить I/O для задачи, которая не CPU-bound (а чистый счёт всё же редок, и то нередко чередуется с выгребанием массива данных/запихиванием результатов на сторадж), то ставить сильнопараллельный юзерленд на такую пшетормозилку нынче будет только особо упёртый любитель...

> Единственное исключение - ситуации, когда ввод-вывод полностью или практически
> полностью обрабатывается ядром: та же маршрутизация сетевых пакетов, например

Фильтрацию сюда же.

PS: http://lkml.org/lkml/2004/8/20/191 :)

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

141. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 02-Окт-11, 07:53 
[...]
>> вычислительных задач (CPU-bound нежели I/O bound). Ну да, крякеры мд5 на
>> скорость тормзить не будут. А вот I/O bound программы (столь типичные
>> для серверов) будут часто стоять колом

[...]
> Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый ввод-вывод
> будет всё равно упираться в не успевающую его прожёвывать программу.

Ввод-вывод не может ни во что упереться, а программа ничего не должна успевать за ядром. Вы путаете причинно-следственную связь: программа через сисколы просит ядро сделать вон то и вон это. А ядро идет и делает. Ядро не может сделать больше чем его попросили. Оно может протормозить с выполнением сискола, но больше чем программе надо - оно в принципе запихнуть в нее не может. Потому что это программа инициирует запрос, а ядро его разруливает.

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

Что значит - единственное исключение? Юзерланд, особенно способный к работе на нескольких процессорах - на раз упрется в I/O (застряв в ядре). Ядро не может упереться в юзерланд потому что это юзерланд запросы инициирует. Ему нельзя впихнуть больше чем он просит.

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

Да ладно вам, те же БД/веб/файлопомойки/роутилки/что там еще - обычно именно I/O bound при правильном подходе. Чисто числокрушильные машины... хм, прости, дядя, они на линуксе обычно. А под опенка вообще есть драйвера с поддержкой OpenCL/CUDA/что там еще, чтобы считать его платформой для крушения чисел? А то видеокарты рвут на этом поприще обычные процессоры на британский флаг просто. Почти все кого колыхали интенсивные вычисления уже используют GPU. Потому что по MIPS/Watt - непобедимо.

> Так что параллельная работа userland-кода всё-таки важнее: для десктопа, для
> web-сервера, для СУБД...

При правильном подходе они будут именно I/O bound. Если это не так - значит где-то ступили. Нет, я конечно понимаю что можно жить в мире тормозных апачей умирающих от 10 юзеров. Но нынче используется нжинкс, который статику вообще лупит как из пушки. В нем нечему проц грузить, собственно. И тормозные скриптобэкэнды имеет смысл жестоко кешировать, как раз чтобы процы разгрузить, ага :))

> Вот, скажем, почтовый релей или распределённая лёгковесная СУБД,
> например, уже может при определённых условиях упереться в ввод-вывод, да. Но
> и в них большая часть работы идёт в userland'е.

Да почти все кроме совсем уж числокрушилок типа кряка хешей и майнинга коинов и прочих формул белков и что там еще - может упереться в именно I/O. Чем ядро быстрее отстреляется, тем лучше: прога меньше висеть будет, ожидая возврата из сискола.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

144. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Окт-11, 04:36 
>[оверквотинг удален]
> [...]
>> Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый ввод-вывод
>> будет всё равно упираться в не успевающую его прожёвывать программу.
> Ввод-вывод не может ни во что упереться, а программа ничего не должна
> успевать за ядром. Вы путаете причинно-следственную связь: программа через сисколы просит
> ядро сделать вон то и вон это. А ядро идет и
> делает. Ядро не может сделать больше чем его попросили. Оно может
> протормозить с выполнением сискола, но больше чем программе надо - оно
> в принципе запихнуть в нее не может. Потому что это программа
> инициирует запрос, а ядро его разруливает.

И-и-и?..

>> Единственное исключение - ситуации, когда ввод-вывод полностью или
>> практически полностью обрабатывается ядром: та же маршрутизация сетевых
>> пакетов, например (т.е. сквозь машину, а не к ней или от неё).
> Что значит - единственное исключение? Юзерланд, особенно способный к работе на нескольких
> процессорах - на раз упрется в I/O (застряв в ядре). Ядро
> не может упереться в юзерланд потому что это юзерланд запросы инициирует.
> Ему нельзя впихнуть больше чем он просит.

Где я писал, что ядро упрётся в userland? Я говорил про собственно ввод-вывод. Который, на минуточку, практически всегда медленнее, чем его может жевать процессор. Или ваши жёсткие диски (вместе с контроллерами) научились отдавать (я молчу про запись) эдак гигабайт в секунду?

>> Почти все задачи практического применения - либо в первую очередь
>> нагружают вычислительные мощности, либо нагружают всё подряд.
> Да ладно вам, те же БД/веб/файлопомойки/роутилки/что там еще - обычно именно I/O
> bound при правильном подходе.

Во-первых, и БД, и Web сильно разные бывают. Web-статика обычно упирается в канал связи, Web-динамика - в CPU. А в случае с БД вообще возможна масса вариантов, в зависимости от количества и качества закладываемой в неё логики. И упирается БД в пропускную способность _дисков_, либо в CPU. Не, конечно, можно при желании достаточно современный SCSI-контроллер засунуть в машину с процом пятилетней давности, и наблюдать, как проц захлёбывается, но мы-то говорим о реальных задачах, не?

> Чисто числокрушильные машины... хм, прости, дядя, они
> на линуксе обычно.

И что? Я где-то утверждал обратное?

> А под опенка вообще есть драйвера с поддержкой
> OpenCL/CUDA/что там еще, чтобы считать его платформой для крушения чисел?

Под опёнок есть те же открытые драйвера, что и под остальные *nix. А насчёт блобов мы как-нибудь отдельно поговорим.

> А то видеокарты рвут на этом поприще обычные процессоры на британский флаг
> просто. Почти все кого колыхали интенсивные вычисления уже используют GPU. Потому
> что по MIPS/Watt - непобедимо.

А кроме числокрушения, вы никаких CPU-bound применений не знаете?

>> Так что параллельная работа userland-кода всё-таки важнее: для десктопа, для
>> web-сервера, для СУБД...
> При правильном подходе они будут именно I/O bound. Если это не так
> - значит где-то ступили.

См. выше.

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

Спасибо, кэп.

>> Вот, скажем, почтовый релей или распределённая лёгковесная СУБД,
>> например, уже может при определённых условиях упереться в ввод-вывод, да. Но
>> и в них большая часть работы идёт в userland'е.
> Да почти все кроме совсем уж числокрушилок типа кряка хешей и майнинга
> коинов и прочих формул белков и что там еще - может
> упереться в именно I/O.

При должном старании - конечно, может. Вот только, похоже, вы сами не сталкивались с этими задачами в промышленных масштабах, ибо очень уж ваша речь напоминает оную у героя рассказа "Срезал"...

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

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

Если хочется чисто потроллить на тему "Линукс рулит, остальные сосут", идите сразу лесом, а?

Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

145. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Michael Shigorin email(ok) on 08-Окт-11, 12:50 
> Я говорил про собственно ввод-вывод. Который, на минуточку, практически всегда
> медленнее, чем его может жевать процессор.

Это на сейчас неверный подход и самоуспокоение.  Конкретно у меня на сборочном ноуте сейчас основной упор именно в процессор -- поскольку сборка в tmpfs и SSD.

Причём вычислительная мощность одного процессорного ядра скорее остановилась, а I/O призадумалось только на HDD, и то 500Mb/s sustained write было не в диковинку на железе дешевле $3000 опять же лет пять тому (помнится, HP DL385 с P400i и 6/8? 2.5" SAS HDD).

> Или ваши жёсткие диски (вместе с контроллерами) научились отдавать (я молчу про запись)
> эдак гигабайт в секунду?

Это они у нас и пять лет тому умели, если уже не больше (одна 16-портовая Areca затыкалась, но две восьмипортовки в тупом режиме более-менее справлялись).  Сейчас же при необходимости организовать такой поток цена вопроса -- меньше килобакса.

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

Поправочка: современный SCSI-контроллер в той машине будет себя чувствовать как родной.  Вероятно, подразумевались SAS/FC HBA. :)

Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

146. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Окт-11, 19:30 
>> Я говорил про собственно ввод-вывод. Который, на минуточку, практически всегда
>> медленнее, чем его может жевать процессор.
> Это на сейчас неверный подход и самоуспокоение.  Конкретно у меня на
> сборочном ноуте сейчас основной упор именно в процессор -- поскольку сборка
> в tmpfs и SSD.

Сборка как бы всегда нагружала в первую очередь процессор. ;) А в случае tmpfs говорить про ввод-вывод вообще не особо уместно. ;) И главное, причём тут самоуспокоение, если сборка как раз идёт не в ядре? :)

> Причём вычислительная мощность одного процессорного ядра скорее остановилась, а I/O призадумалось
> только на HDD, и то 500Mb/s sustained write было не в
> диковинку на железе дешевле $3000 опять же лет пять тому (помнится,
> HP DL385 с P400i и 6/8? 2.5" SAS HDD).

МегаБАЙТ или мегаБИТ? ;)

>> Или ваши жёсткие диски (вместе с контроллерами) научились отдавать (я молчу про запись)
>> эдак гигабайт в секунду?
> Это они у нас и пять лет тому умели, если уже не
> больше (одна 16-портовая Areca затыкалась, но две восьмипортовки в тупом режиме
> более-менее справлялись).  Сейчас же при необходимости организовать такой поток цена
> вопроса -- меньше килобакса.

AFAIK, поток от одного контроллера не параллелится, прерывание-то одно. И главное - куда этот поток пойдёт? Основных вариантов по сути три: на другой дисковый контроллер, на обработку в юзерленд и в сеть. В первом случае параллелизация процессов в CPU действительно даст большой выигрыш, в третьем будет бесполезна, а во втором - зависит от задачи: чем сложнее обработка, тем меньше влияние "пропускной способности" ядра.

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

>> Не, конечно, можно при желании достаточно современный SCSI-контроллер засунуть
>> в машину с процом пятилетней давности, и наблюдать, как проц захлёбывается,
>> но мы-то говорим о реальных задачах, не?
> Поправочка: современный SCSI-контроллер в той машине будет себя чувствовать как родной.
>  Вероятно, подразумевались SAS/FC HBA. :)

Эм, а чем это SAS не SCSI? :)

Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

147. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Michael Shigorin email(ok) on 09-Окт-11, 21:05 
> Сборка как бы всегда нагружала в первую очередь процессор. ;)

Смотря какая, сишное барахлишко уже довольно давно летит струёй, не загружая ядра полностью, если не поддать -j до N+1..2.  Плюсовое -- да, наваливается на CPU.

> А в случае tmpfs говорить про ввод-вывод вообще не особо уместно. ;)

Этот случай был упомянут "хозяйке на заметку" :)

> И главное, причём тут самоуспокоение, если сборка как раз идёт не в ядре? :)

А I/O где идёт?

>> и то 500Mb/s sustained write было не в диковинку [...]
> МегаБАЙТ или мегаБИТ? ;)

Байт, конечно (иначе бы написал Mbps, хотя согласен, лучше уточнить сразу).

> AFAIK, поток от одного контроллера не параллелится, прерывание-то одно.

Ну так их и несколько ставят порой... в стораджевых драйверах я даже не чайник, что там с/от SMP, не знаю -- могу техдира спросить при случае.

> И главное - куда этот поток пойдёт?

Скорее уж не "куда пойдёт", а "какой поток упрётся в одно доступное ядро".

> Эм, а чем это SAS не SCSI? :)

Разъёмчиком не вышел. :)

Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

64. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 20:39 
>> Это освещено в документации. Которой OpenBSD небезосновательно гордится.
> В каком месте документации представлены доказательства
> слов "proactively secure"? Хотелось бы увидеть полный список
> вещей, посвященных безопасности.

Гм. Какое отношение это имеет к обсуждаемой теме? Ну да ладно.

Единого списка, AFAIK, нет. Зато прямо на заглавной странице их сайта, например, есть ссылки "Security" и "Crypto". ;) Впрочем, там скорее обзорно. Ещё можно соответствующие доклады почитать, http://www.openbsd.org/papers/ . Изменения в GCC описаны в gcc-local(1). Остальное упоминается в соответствующих man-страницах: malloc(3), imsg_init(3), securelevel(7) и т.д. То есть когда вам надо узнать о безопасности того или иного объекта, вы просто читаете страницу руководства об этом объекте.

Может, централизованный список и был бы полезен... для рекламных целей. :) Ибо для чего ещё он нужен, представляю плохо. Заходить самому и гордиться? Смешно же.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

66. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 21:11 
> Гм. Какое отношение это имеет к обсуждаемой теме? Ну да ладно.

Ну, темы тут обсуждаются всё-таки разные, не только новость.

> в GCC описаны в gcc-local(1). Остальное упоминается в соответствующих man-страницах: malloc(3),

Не остальное, а куцый остаток. Всё самое интересное не упоминается ни где, кроме информационных разделов, презентаций, ChangeLog'ов и релизных анонсов.

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

Для peer review он нужен.

Хотя проще и надёжнее, конечно, верить разработчикам OpenBSD на слово. Особенно после их меткого и оперативного анализа уязвимости в реализации IPv6, найденной Core Security. А также после виртуозной и безошибочной реализации W^X (об ошибках, которых не было, естественно, публику никто не уведомлял - не было ведь ;). После успехов этих замечательных людей на поприще ИБ, включая взаимодействие с экспертным сообществом, лично у меня сложилось о них как об экспертах однозначно положительное мнение. ;) Но главное - эти люди надёжные, им можно верить. ;)

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

72. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 22:21 
>> Может, централизованный список и был бы полезен... для рекламных целей. :) Ибо
>> для чего ещё он нужен, представляю плохо. Заходить самому и гордиться?
>> Смешно же.
> Для peer review он нужен.

Если уж делать нормальное ревью, то всё равно надо лезть в код. А то, например, заявлено будет, что SSP поддерживается, а на деле выяснится, что он по умолчанию отключен. Вроде бы и не соврали, конечно...

> Хотя проще и надёжнее, конечно, верить разработчикам OpenBSD на слово. Особенно после
> их меткого и оперативного анализа уязвимости в реализации IPv6, найденной Core
> Security. А также после виртуозной и безошибочной реализации W^X (об ошибках,
> которых не было, естественно, публику никто не уведомлял - не было
> ведь ;). После успехов этих замечательных людей на поприще ИБ, включая
> взаимодействие с экспертным сообществом, лично у меня сложилось о них как
> об экспертах однозначно положительное мнение. ;) Но главное - эти люди
> надёжные, им можно верить. ;)

А если без сарказма? И главное - если такой вот централизованный список будет опубликован, это ли не будет как раз "верить на слово", вместо того, чтобы самому смотреть детали?

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

76. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 26-Сен-11, 23:45 
>[оверквотинг удален]
> конечно...
>> Хотя проще и надёжнее, конечно, верить разработчикам OpenBSD на слово. Особенно после
>> их меткого и оперативного анализа уязвимости в реализации IPv6, найденной Core
>> Security. А также после виртуозной и безошибочной реализации W^X (об ошибках,
>> которых не было, естественно, публику никто не уведомлял - не было
>> ведь ;). После успехов этих замечательных людей на поприще ИБ, включая
>> взаимодействие с экспертным сообществом, лично у меня сложилось о них как
>> об экспертах однозначно положительное мнение. ;) Но главное - эти люди
>> надёжные, им можно верить. ;)
> А если без сарказма? И главное - если такой вот централизованный список

Да я уже устал повторять. И не я один. В IRC эта тема за последние несколько лет поднималась на разных каналах не один десяток раз. В листах рассылки, вроде, тоже проскакивало. И все, кто думал своей головой и не затыкал уши, выводы давно сделали.

Суть в том, что разработчики OpenBSD отказались изучать возможности эксплуатации уязвимости в коде IPv6 и объявили её DoS-уязвимостью. После чего Core Security представила рабочий PoC-эксплойт.

Это при том, что DoS-уязвимости не считаются опасными в OpenBSD, и заплатки на них не анонсируются как обновления безопасности.

Более того, в качестве меры защиты от эксплуатации Core Security предложила разработчикам идею и предварительный патч в несколько срок, с примитивной реализацией W^X для адра (аналог KERNEXEC на базе сегментов x86). Где W^X в ядре? Где гарантии, что разработчики OpenBSD не проигнорируют уязвимости в будущем? Где документация для проведения peer review с описанием принципов и путей их реализации? Где, хотя бы, детальные комментарии в коде? Ничего нет. Вы как хотите, а я таким экспертам доверять не стану.

> будет опубликован, это ли не будет как раз "верить на слово",
> вместо того, чтобы самому смотреть детали?

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

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

105. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 03:47 
>[оверквотинг удален]
>>> об экспертах однозначно положительное мнение. ;) Но главное - эти люди
>>> надёжные, им можно верить. ;)
>> А если без сарказма? И главное - если такой вот централизованный список
> Да я уже устал повторять. И не я один. В IRC эта
> тема за последние несколько лет поднималась на разных каналах не один
> десяток раз. В листах рассылки, вроде, тоже проскакивало. И все, кто
> думал своей головой и не затыкал уши, выводы давно сделали.
> Суть в том, что разработчики OpenBSD отказались изучать возможности эксплуатации уязвимости
> в коде IPv6 и объявили её DoS-уязвимостью. После чего Core Security
> представила рабочий PoC-эксплойт.

http://marc.info/?l=openbsd-misc&m=117404837006368&w=2

Ошибкой OpenBSD-шников было в первую очередь то, что они доверились (скороспешному) анализу ребят из Core Security. То, что это возможность для удалённого выполнения кода, выяснилось позднее. У Core Security на это выяснение ушла неделя. Да, они молодцы, что докопались до самого конца. Но представление разработчиков OpenBSD как игнорирующих проблему - это уже, мягко говоря, перебор.

> Более того, в качестве меры защиты от эксплуатации Core Security предложила разработчикам
> идею и предварительный патч в несколько срок, с примитивной реализацией W^X
> для адра (аналог KERNEXEC на базе сегментов x86). Где W^X в
> ядре? Где гарантии, что разработчики OpenBSD не проигнорируют уязвимости в будущем?

По поводу игнорирования см. выше.

Насчёт W^X в ядре, полноценного, насколько знаю, нет. Однако записать в область ядра процесс не может изначально, только само ядро может "ошибиться" и перезаписать собственный код. Учитывая, что страницы кода и данных не смежные, нужно подсунуть в какой-то функции ядра вместо указателя на выделенную для данных область памяти - указатель на область кода ядра. Как это сделать, не имея уже исполнения собственного кода в ядре либо возможности перезаписать код (т.е., выполненной задачи), я пока что-то не представляю.

> Где документация для проведения peer review с описанием принципов и путей
> их реализации?

Вы повторяетесь. :)

> Где, хотя бы, детальные комментарии в коде? Ничего нет.

Гм. А какие вам нужны комментарии к этому?

case DIOCGETRULE:
        if (((struct pfioc_rule *)addr)->action ==
            PF_GET_CLR_CNTR)
                return (EACCES);
        break;

Или почему этот комментарий не детальный?

/*
* Check if a process is allowed to fiddle with the memory of another.
*
* p = tracer
* t = tracee
*
* 1.  You can't attach to a process not owned by you or one that has raised
*     its privileges.
* 1a. ...unless you are root.
*
* 2.  init is always off-limits because it can control the securelevel.
* 2a. ...unless securelevel is permanently set to insecure.
*
* 3.  Processes that are in the process of doing an exec() are always
*     off-limits because of the can of worms they are. Just wait a
*     second.
*/
int
process_checkioperm(struct proc *p, struct proc *t)
{

> Вы как хотите, а я таким экспертам доверять не стану.

Ваше право.

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

Список с галочками (общий, не только по безопасности) раньше был, прямо на сайте. Толку от него было только чуть, никто не рвался в бой. Ну и убрали, ибо лучше без списка, чем с неактуальным. Правда, как источник информации для ревью он не расценивался.

А насчёт документации - давайте оформим ваше претензию серьёзно. Что, зачем и как должно быть. Если возможно, с примерами. А то язвить-то много ума не надо, но это как-то не конструктивно. :)

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

112. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 28-Сен-11, 06:31 
>[оверквотинг удален]
>>>> надёжные, им можно верить. ;)
>>> А если без сарказма? И главное - если такой вот централизованный список
>> Да я уже устал повторять. И не я один. В IRC эта
>> тема за последние несколько лет поднималась на разных каналах не один
>> десяток раз. В листах рассылки, вроде, тоже проскакивало. И все, кто
>> думал своей головой и не затыкал уши, выводы давно сделали.
>> Суть в том, что разработчики OpenBSD отказались изучать возможности эксплуатации уязвимости
>> в коде IPv6 и объявили её DoS-уязвимостью. После чего Core Security
>> представила рабочий PoC-эксплойт.
> http://marc.info/?l=openbsd-misc&m=117404837006368&w=2

http://pwnies.com/archive/2007/winners/#lamestvendor
http://www.coresecurity.com/content/open-bsd-advisorie

> Ошибкой OpenBSD-шников было в первую очередь то, что они доверились (скороспешному) анализу
> ребят из Core Security. То, что это возможность для удалённого выполнения

:))) Бедные, наивные - доверились! :) Если сходить по вашей же ссылке, из обтекаемого описания, составленного Тео (обратите внимание, как смещены акценты в сравнении с таймлайном на сайте Core Security), становится ясно, что у Core были опасения на счёт эксплуатабельности уязвимости, но ребята из OpenBSD их проигнорировали. Видимо, к понижению оценки опасности без оснований их тоже ребатя из Core склонили - наивных, таких, разработчиков "самой безопасной ОС в мире". ;)

> кода, выяснилось позднее. У Core Security на это выяснение ушла неделя.
> Да, они молодцы, что докопались до самого конца. Но представление разработчиков
> OpenBSD как игнорирующих проблему - это уже, мягко говоря, перебор.

Это ровно то, что произошло. Проблема не в самой уязвимости и не в том, в какие сроки она была закрыта, а в неадекватной оценке этой уязвимости и в выпуске уведомления класса RELIABILITY FIX. И это при том, что ребята из Core свои опасения высказали сразу.

Хинт: правильным поведением в этой ситуации был бы выпуск SECURITY FIX'а с пояснением, что существует вероятность выполнения произвольного кода. И вот затем, если бы такая вероятность была на 100% опровергнута, можно было б продаунгрейдить статус уведомления до RELIABILITY FIX. А не наоборот.

> По поводу игнорирования см. выше.

О сроках выхода исправления я и без вас был в курсе. Специально для вас переформулирую в части игнорирования: где гарантия, что разработчики OpenBSD не проигнорируют потенциальную возможность эксплуатации уязвимости и не дезинформируют сообщество и меня, в том числе, о степени важности исправления? Отдельно подчеркну, что уязвимость была удалённая, и недооценивать такую уязвимость - это, с моей точки зрения, недопустимо "вдвойне".

> Насчёт W^X в ядре, полноценного, насколько знаю, нет. Однако записать в область
> ядра процесс не может изначально, только само ядро может "ошибиться" и

Очень правильно вы взяли в кавычки. Именно так проводится подавляющее большинство атак на ядра - им помогают "ошибиться". ;)

> перезаписать собственный код. Учитывая, что страницы кода и данных не смежные,

В каком смысле не смежные? Границы сегментов на x86 одинаковые, а в amd64 и сегментов-то нет - одна страничная логика. Вы хотите сказать, что страницы стеков и данных в ядре OpenBSD теперь неисполняемые по умолчанию? Вам это кто-то подтвердил?

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

Вы всё смешали и упростили. Всё не так. И тот факт, что вы не представляете, как подсунуть - он о чём мне должен сказать? И как мне нужно реагировать на это - особенно в свете ваших комментариев о чьей-то квалификации? Как минимум через указание индекса массива на элемент за его границами и адресная арифметика на указателях позволяют обратиться к произвольной (или условно и достаточно произвольной) области памяти, не перезаписывая указатель непосредственно. Ну и способы эксплуатации внедрением кода не исчерпываются. Представьте, что будет, если всего-то нолик в какой-нибудь process->ps_cred->p_ruid "какого-нибудь" процесса записать.

>> Где документация для проведения peer review с описанием принципов и путей
>> их реализации?
> Вы повторяетесь. :)

Вы заметили!!!111 Я в шоке!!!11

Если оставить по два восклицательных знака, в этом даже не будет сарказма.

> Гм. А какие вам нужны комментарии к этому?
> Или почему этот комментарий не детальный?

Нет комментариев, достаточно полных, чтобы заменить документацию. А самодокументированный код не может заменить документацию даже в принципе - он даёт преставление о том, что делается, а не о том, что должно быть сделано и *почему*. Сами ребята из OpenBSD предпочитают писать дрова по спецификациям, а как доходит дело до стороннего анализа их творений - что? Двойные стандарты: теперь код - это спецификация? Пример с CARP я уже приводил - спецификации на протокол нет, а протокол есть.

>> Вы как хотите, а я таким экспертам доверять не стану.
> Ваше право.

Именно. И вас переубеждать сверх разумного не стану.

> Список с галочками (общий, не только по безопасности) раньше был, прямо на
> сайте. Толку от него было только чуть, никто не рвался в
> бой. Ну и убрали, ибо лучше без списка, чем с неактуальным.
> Правда, как источник информации для ревью он не расценивался.

Как, оказывается, сложно разработчикам поддерживать документацию в актуальном состоянии!

> А насчёт документации - давайте оформим ваше претензию серьёзно. Что, зачем и
> как должно быть. Если возможно, с примерами. А то язвить-то много
> ума не надо, но это как-то не конструктивно. :)

У вас есть пища для размышлений. Хотите - оформляйте. А я не смогу использовать OpenBSD в работе, даже если вдруг захочу - не подходит по ряду показателей. К тому же, я догадываюсь, что ответит Тео и остальные. ;) Вы, уверен, тоже. ;)

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

73. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 26-Сен-11, 22:32 
>Особенно после их меткого и оперативного анализа уязвимости в реализации IPv6, найденной Core Security. А также после виртуозной и безошибочной реализации W^X (об ошибках, которых не было, естественно, публику никто не уведомлял - не было ведь ;). После успехов этих замечательных людей на поприще ИБ, включая взаимодействие с экспертным сообществом

Скажите, а где можно почитать подробнее про все эти интересные и увлекательные истории?

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

77. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 27-Сен-11, 00:12 
> Скажите, а где можно почитать подробнее про все эти интересные и увлекательные
> истории?

В комментах на опеннете я неоднократно описывал ситуацию. Можете почитайть таймлайн взаимодействия по уязвимости в IPv6 на сайт Core Security:
http://www.coresecurity.com/content/open-bsd-advisorie

А также сходить на лист рассылки OpenBSD и задать разработчикам конкретные вопросы, например:
- какие меры защиты реализованы, как
- есть ли документация по ним; если нет, то почему
- каковы планы по доработке-развитию мер защиты на будущее
- почему не реализована защита от брутфорса на ASLR путём задержки порождения процессов-потомков в случае краха одного из них
- почему не реализованы <другие меры защиты, которые вас интересуют>
- какие изъяны были выявлены в реализации W^X, когда были исправлены
- был ли содержательный анонс исправлений; если не было, то почему
- есть ли аналог W^X для памяти ядра; если нет, то почему
- что помешало раньше реализовать запрет на маппинги по нулевому адресу и поддержку PIE
И т.д.

Поищите на листах рассылки по безопасности на тему OpenBSD. Вот, например:
http://seclists.org/bugtraq/2004/Sep/202

Можете подписаться на DailyDave, Full-Disclosure или oss-security и поинтересоваться взглядами экспертного сообщенства на безопасность в OpenBSD. Если хотите более живой беседы, спросите там же, кто и на каких каналах в IRC готов ответить на ваши вопросы.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

79. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 27-Сен-11, 00:41 
Хм. Складывается такое впечатление, что разработчики OpenBSD среди профессиональных экспертов по безопасности считаются этакими позерами, много заявляющими, но ничего не делающими.
Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

81. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 27-Сен-11, 02:30 
Ничего не делают - слишком громко сказано. Но многое для существенной защиты ОС и окружения в современных условиях, действительно, либо не делают, либо делают с опозданием, либо не доводят до конца, либо делают хуже, чем возможно сделать в принципе.
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

83. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 27-Сен-11, 03:41 
> Поищите на листах рассылки по безопасности на тему OpenBSD. Вот, например:
> http://seclists.org/bugtraq/2004/Sep/202

Аффтар местами, конечно, по делу прошёлся (с PaX действительно по-дурацки вышло, скажем). Но почему-то решил, например, что разделение привилегий между процессами - бесполезная вещь. То ли он решил, что программа от имени пользователя обязательно найдёт уязвимость в ядре, то ли ещё что-то странное... Так что о его квалификации лично я в итоге ещё менее высокого мнения. :)

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

84. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 27-Сен-11, 05:13 
> Аффтар местами, конечно, по делу прошёлся (с PaX действительно по-дурацки вышло, скажем).

Это как раз не главное.

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

Не программа, а skilled attacker. Эту критику нужно воспринимать в контексте полного (на тот момент) невнимания команды OpenBSD к защите ядра, полной тишины на эту тему в слайдах, а также слишком поверхностной и потому некорректной оценки эффективности упомянутых защит.

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

> о его квалификации лично я в итоге ещё менее высокого мнения.
> :)

Этот не очень квалифицированный аффтар недавно получил Pwnie for Lifetime Achievement. ;)
http://pwnies.com/winners/#lifetime

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

89. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 27-Сен-11, 14:01 
>> Но почему-то решил, например, что разделение привилегий между процессами - бесполезная
>> вещь. То ли он решил, что программа от имени пользователя обязательно
>> найдёт уязвимость в ядре, то ли ещё что-то странное... Так что
> Не программа, а skilled attacker. Эту критику нужно воспринимать в контексте полного
> (на тот момент) невнимания команды OpenBSD к защите ядра,

В плане, невнимания к защите ядра? Сначала разработали технологию, потом начали внедрять. Тот же SSP в ядре появился тогда, в 2003:

revision 1.6
date: 2003/05/13 06:11:11;  author: tedu;  state: Exp;  lines: +10 -1
support for propolice in the kernel.
some style input itojun@ tdeval@ toby@
tested, mostly by deraadt, on i386, macppc, vax, sparc64
ok deraadt@ miod@

Поясните, что вы подразумеваете под защитой ядра? И в чём конкретно претензия?

> полной тишины
> на эту тему в слайдах, а также слишком поверхностной и потому
> некорректной оценки эффективности упомянутых защит.

В конкретно отмеченном мною случае более поверхностным _местами_ показал себя именно этот эксперт.

> Смысл в разделении привилегий существует только при условии надлежащей защиты ядра. Спорить
> на эту тему можно только с неуловимыми джо, однако презентация явно
> рассчитана не только на них.

Погодите, погодите. Эффект любой защиты в конкретной ситуации может быть нивелирован брешью "на соседнем участке". Это действительно, понятно даже ёжику. Но по вашей логике, получается, вообще ничего делать не надо, если только не всё сразу? Была произведена подмена темы, вы разве не видите? Вместо защитного механизма речь зашла о совсем другом участке кода. Из серии: "Ну и что, что 4x4, всё равно задних сидений нет". Это был банальный софизм, а вы его ещё и защищаете почему-то.

>> о его квалификации лично я в итоге ещё менее высокого мнения.
>> :)
> Этот не очень квалифицированный аффтар недавно получил Pwnie for Lifetime Achievement.
> ;)
> http://pwnies.com/winners/#lifetime

Не лично, прошу заметить. ;)

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

95. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 27-Сен-11, 19:06 
> В плане, невнимания к защите ядра? Сначала разработали технологию, потом начали внедрять.
> Тот же SSP в ядре появился тогда, в 2003:

Это всего лишь защита от линейных переполнений, которая на тот момент была (а может и до сих пор) ослаблена постоянным canary-значенем, которое не менялось при обработке системных вызовов - одна утечка, и защиты нет.

> Поясните, что вы подразумеваете под защитой ядра? И в чём конкретно претензия?

Под защитой ядра я подразумеваю наличие механизмов защиты ядра от эксплуатации различных классов уязвимостей. Наличие ослабленной SSP от линейных переполнений на стеке - это недоразумение и абсолютно ничего существенного (что, кстати, доказывается бесполезностью SSP для защиты от впоследствии опубликованных уязвимостей).

> В конкретно отмеченном мною случае более поверхностным _местами_ показал себя именно этот
> эксперт.

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

> Погодите, погодите. Эффект любой защиты в конкретной ситуации может быть нивелирован брешью

Именно. Но сейчас ваши доводы звучат, как оправдание закрепление мощной лобовой брони танка несколькими болтами на алюминиевый каркасс. Попадание снаряда может не пробить броню, но танк раскурочит наверняка. Компренде?

Разделение привилегий (а также различные jail'ы и MAC-системы) и защита ядра являются звеньями одной цепи, прочность которой равна прочности самого слабого звена.

С отзывом привилегий (privilege revocation) дело обстоит иначе: если процессу, допустим, запрещено использовать некий системный вызов либо целиком, либо с неким набором аргументов, обработкой которых занимается некий уязвимый код, то такой запрет выполнит задачу по предотвращению эксплуатации уязвимостей в отдельных участках кода (тот же эффект достигается за счёт выкидывания из ядра лишнего кода тем или иным способом). Это, насколько я могу судить, и имел ввиду PaX Team, говоря о бесполезности privilege separation (в свете незащищённого ядра) и полезности privilege revocation (как раз для защиты такого ядра).

Почему для вас это не очевидно? Возможно, у вас ещё остались иллюзии о безопасности ядра, код которого пишется "с безопасностью в уме" и якобы проходит постоянный аудит. У меня, после публикации уязвимости в коде IPv6 и локальных root-уязвимостей по причине банального NULL pointer dereference, таких иллюзий не осталось. А у PaX Team их не было уже на тот момент. Что кагбе говорит о его низкой квалификации, да. ;)

> "на соседнем участке". Это действительно, понятно даже ёжику. Но по вашей

Это заблуждение, которое различным ёжиком привили люди, вроде Бернштейна и разработчиков OpenBSD, отвлекая внимание от проблемы самого слабого звена. Которая, казалось бы, тем же ёжикам вполне известна и нередко цитируюется. Но, вот, есть какие-то трудности с тем, чтобы сложить 2 и 2.

> логике, получается, вообще ничего делать не надо, если только не всё

По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или наоборот.

> сразу? Была произведена подмена темы, вы разве не видите? Вместо защитного

Не вижу. Обсуждаем звенья одной цепи.

> механизма речь зашла о совсем другом участке кода. Из серии: "Ну
> и что, что 4x4, всё равно задних сидений нет". Это был
> банальный софизм, а вы его ещё и защищаете почему-то.

Этот "софизм" совпадает с моими собственными выводами.

> Не лично, прошу заметить. ;)

В смысле? Лично за наградой не явился? ;)

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

103. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 03:23 
>> В плане, невнимания к защите ядра? Сначала разработали технологию, потом начали внедрять.
>> Тот же SSP в ядре появился тогда, в 2003:
> Это всего лишь защита от линейных переполнений, которая на тот момент была
> (а может и до сих пор) ослаблена постоянным canary-значенем, которое не
> менялось при обработке системных вызовов - одна утечка, и защиты нет.

Проверил сейчас GCC в базе, канарейка генерится уникальная для каждой функции на базе адреса этой самой функции. Значение между вызовами не меняется:

1c0007aa:       a1 40 31 00 3c          mov    0x3c003140,%eax
1c0007af:       89 45 fc                mov    %eax,0xfffffffc(%ebp)
1c0007b2:       31 c0                   xor    %eax,%eax
<...>
1c0007ce:       8b 55 fc                mov    0xfffffffc(%ebp),%edx
1c0007d1:       33 15 40 31 00 3c       xor    0x3c003140,%edx
1c0007d7:       74 0c                   je     1c0007e5 <cantest+0x41>
1c0007d9:       c7 04 24 1c 00 00 3c    movl   $0x3c00001c,(%esp)
1c0007e0:       e8 17 fd ff ff          call   1c0004fc <__init+0x2c>

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

В вашем ненаглядном PaX, как я понимаю, дела обстоят лучше? Что там генерится?

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

А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся в том же PaX технологий?

>> В конкретно отмеченном мною случае более поверхностным _местами_ показал себя именно этот
>> эксперт.
> Если бы он допустил технический ляп, я бы с вами согласился. Но
> в данном случае вы пытаетесь выдать за ошибку разницу между его
> и вашим мнением.

Ошибка (не столько техническая - назвать страуса павлином, - сколько логическая, да) в том, что он прямо говорит: "разделение привилегий бесполезно, так как неуязвимых ядер не бывает". Простите, но это бред. Вы сами ниже пишете, что, мол, "По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или наоборот". Вот, одну вещь сделали. Ваша (или, по крайней мере, товарища Альбертса) претензия в том, что это не произошло одновременно? Ну извините. Может, PaX/GrSecurity тоже за ночь появились? Или напомнить об уязвимостях в самих этих защитных механизмах? Я не User294 и кричать epic fail по этому поводу не собираюсь, косяки у всех бывают. Но как-то думать над тем, что пишешь, тоже надо. Ну или отвечать за свои слова.

Я не пойму, что вы покрываете автора текста, он вам денег должен? :)

>> Погодите, погодите. Эффект любой защиты в конкретной ситуации может быть нивелирован брешью
> Именно. Но сейчас ваши доводы звучат, как оправдание закрепление мощной лобовой брони
> танка несколькими болтами на алюминиевый каркасс. Попадание снаряда может не пробить
> броню, но танк раскурочит наверняка. Компренде?
> Разделение привилегий (а также различные jail'ы и MAC-системы) и защита ядра являются
> звеньями одной цепи, прочность которой равна прочности самого слабого звена.

Спасибо, кэп.

> С отзывом привилегий (privilege revocation) дело обстоит иначе: если процессу, допустим,
> запрещено использовать некий системный вызов либо целиком, либо с неким набором
> аргументов, обработкой которых занимается некий уязвимый код, то такой запрет выполнит
> задачу по предотвращению эксплуатации уязвимостей в отдельных участках кода (тот же
> эффект достигается за счёт выкидывания из ядра лишнего кода тем или
> иным способом). Это, насколько я могу судить, и имел ввиду PaX
> Team, говоря о бесполезности privilege separation (в свете незащищённого ядра) и
> полезности privilege revocation (как раз для защиты такого ядра).

Я не люблю строить догадки, кто что имел в виду. Есть конкретные слова: "privilege revocation does actually make sense however privilege separation (not seperation) doesn't. for noone has a bugfree kernel". Если он хотел сказать что-то другое - сочувствую, конечно, но подтверждений этому не вижу.

> Почему для вас это не очевидно? Возможно, у вас ещё остались иллюзии
> о безопасности ядра, код которого пишется "с безопасностью в уме" и
> якобы проходит постоянный аудит.

Я смотрю на количество errata в ядре Linux и ядре OpenBSD, например. В OpenBSD оно с каждым годом стремительно уменьшается. Вы, конечно, можете крикнуть: "потому что скрывают!". Но я пока не видел этому подтверждений, хотя честно читаю source-changes@, и разглядываю все настораживающие коммиты.

>> "на соседнем участке". Это действительно, понятно даже ёжику. Но по вашей
> Это заблуждение, которое различным ёжиком привили люди, вроде Бернштейна и разработчиков
> OpenBSD, отвлекая внимание от проблемы самого слабого звена.

Какое заблуждение? Вы вообще о чём? О том, что изоляция привилегий полезна? Я не пойму, вы на пару с этим товарищем не понимаете, против чего вообще эта защитная мера нужна, что ли? Ядро она не защищает, да, ну так и доклад-то был не "защитные техники ядра OpenBSD", не? Каша у вас какая-то.

>> логике, получается, вообще ничего делать не надо, если только не всё
> По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или
> наоборот.

Это ортогональные вещи, почему г-н Альбертс сплёл их вместе - только ему и известно.

>> сразу? Была произведена подмена темы, вы разве не видите? Вместо защитного
> Не вижу. Обсуждаем звенья одной цепи.

Да, но РАЗНЫЕ звенья. Вот вам цепь, пять звеньев. Первое, второе и третье держат до 50 ньютонов, четвёртое до 30, пятое до 20. Усилили пятое, теперь оно тоже держит 50 ньютонов. Вопль со стороны: "да нафига делали, всё равно порвётся". Цена этому воплю знаете, какая?

>> механизма речь зашла о совсем другом участке кода. Из серии: "Ну
>> и что, что 4x4, всё равно задних сидений нет". Это был
>> банальный софизм, а вы его ещё и защищаете почему-то.
> Этот "софизм" совпадает с моими собственными выводами.

Печально.

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

110. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 28-Сен-11, 05:12 
> будет известно. Хреново. Если не стоковое, то нужна не просто утечка,
> а из данного системного вызова. Две разных уязвимости на один системный

Уязвимость к утечке может быть где угодно. Главное, чтобы утечка произошла с адреса на общем стеке, где лежит canary-значение, сохранившееся после предыдущего сисколла.

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

И теоретически, и практически. Вы слишком быстро всё списываете со счетов. Skilled attacker уж точно так не поступит, а упрётся до последнего, если компрометация системы это окупит.

> В вашем ненаглядном PaX, как я понимаю, дела обстоят лучше? Что там
> генерится?

Лучше, но, во-первых, лишь с недавнего времени, а во-вторых, PaX не имеет никакого отношения к SSP. Так вот, с недавнего времени для предотвращения утечек со стека PaX Team разработал плагин для GCC >= 4.5, который зануляет стек сисколлов перед использованием. Правда, не целиком, а на базе эвристики - иначе, оверхед слишком велик.

> А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся
> в том же PaX технологий?

Я могу сказать, что эксплуатацию через userland pointer dereference PaX останавливает на 100% на x86, с высокой вероятностью на amd64 (требуется утечка памяти для обхода защиты), а NULL pointer dereference (подкласс предыдущего класса) останавливает везде, благодаря обычному уже запрету на маппинги по нулевому адресу (код которого, кстати, давно включён в апстрим).

Эксплуатацию через возврат на данные в памяти ядра, как в случае IPv6-уязвимости в OpenBSD, PaX останавливает на 100%. Утечки памяти при её выделении юзерспейсу - на 100%. Переполнения буферов в динамической памяти при copy_from_user - процент назвать не берусь, но общее мнеие, что USERCOPY весьма эффективен в этом.

Если коротко, то почти все уязвимости, которые были упобликованы для линукса, либо невозможно (не считая DoS-эффекта - тут линукс в аутсайдерах), либо значительно сложнее эксплуатировать на PaX-ядрах, за исключением редчайших случаев arbitrary read+write или более частых утечек + arbitrary write (при некотором везении).

> Ошибка (не столько техническая - назвать страуса павлином, - сколько логическая, да)

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

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

> в том, что он прямо говорит: "разделение привилегий бесполезно, так как
> неуязвимых ядер не бывает". Простите, но это бред. Вы сами ниже

Вы упорно игнорируете контекст сказанного. Следуя вашей интерпретации, PaX Team считает бесполезным и отделение суперпользователя от обычных пользователей, и MAC-системы в части функций, не ограничивающих доступ к ядру, и само разделение привилегий исполняемых страниц памяти - чего уж там, если компрометация непривилегированного процесса равносильна компрометации всей системы. For noone has a bugfree kernel же.

Где те границы, не позволяющие довести мнение компетентного человека до абсолютного абсурда? Вы их стёрли, цепляясь к словам и утверждая, что контекст неважен. Фактически, следуя вашей интерпретации, PaX Team в обзоре презентации говорит одно, а на деле занимается соврешенно противоположным, укрепляя защиту ядра от атак со стороны пользовательских процессов. Всё, включая факты и здравый смысл, противоречит вашей гипотезе. Единственное, что можно было бы утверждать, имея хоть какие-то основания - это то, что PaX Team слишком резко сказал сгоряча. Однако, сомнений в его хладнокровии я не слышал - только сомнения в квалификации.

Если вам этих доводов мало, мне больше возразить нечего.

> пишете, что, мол, "По моей логике, реализовав разделение привилегий, нужно браться
> за усиление ядра, или наоборот". Вот, одну вещь сделали. Ваша (или,
> по крайней мере, товарища Альбертса) претензия в том, что это не

Вы спутали автора перепоста на bugtraq с PaX Team aka pipacs - он известен только под псевдонимами.

> произошло одновременно? Ну извините. Может, PaX/GrSecurity тоже за ночь появились? Или
> напомнить об уязвимостях в самих этих защитных механизмах? Я не User294

Претезния в том, что эти риски, обусловленные незащищённым ядром, не были даже упомянуты (!) в обсуждаемой презентации, а меры по их снижению (механизмы защиты ядра) не реализованы до сих пор, спустя почти семь лет (!), а вовсе не одну ночь.

Об уязвимости - единственной - я и без вас помню. Остальные уявзимости были найдены в изначальном коде ядра, и если поддавались эксплуатации, то в обход мер защиты PaX/Grsecurity, а не путём их отключения или нахождения недокументированного изъяна.

> и кричать epic fail по этому поводу не собираюсь, косяки у
> всех бывают. Но как-то думать над тем, что пишешь, тоже надо.
> Ну или отвечать за свои слова.

Ну-ка, ну-ка!.. В свете упоминания ответственности за слова, у вас никаких претензий к разработчикам OpenBSD нет, *случайно*?

> Я не пойму, что вы покрываете автора текста, он вам денег должен?
> :)

Вы, действительно, не понимаете. Как ещё объяснить, я уже не знаю - как донести до вас очевидное, что как сколько ядром не называй и из схем не исключай, оно останется большим, уязвимым, абсолютно привилегированным процессом с полностью открытым внешним интерфейсом.

> Спасибо, кэп.

Ну тогда я не понимаю, почему вам не нравится, что оспаривая состоятельность принципа разделения привилегий, я указываю на изъяны в ядре. Совершенно не понимаю.

> Я не люблю строить догадки, кто что имел в виду. Есть конкретные

А знаете, что? IRC-сеть OFTC, канал #pax, ник pipacs - выскажите ваши вопросы и сомнения непосредственно виновнику торжества непонимания. Что мы, действительно, догадки сторим...

> слова: "privilege revocation does actually make sense however privilege separation (not
> seperation) doesn't. for noone has a bugfree kernel". Если он хотел
> сказать что-то другое - сочувствую, конечно, но подтверждений этому не вижу.

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

> Я смотрю на количество errata в ядре Linux и ядре OpenBSD, например.

Я вам ещё одно количественное сравнение предлагаю: назвать хотя бы одного (!) эксперта в области безопасности, котороый бы входил в команду разработчиков OpenBSD или хотя бы сотрудничал с ними на более-менее постоянной основе. Это я кагбе намекаю на косвенное следствие из разницы в популярности двух ОС и "шарма" Тео и ко. в вопросах привлечения людей со стороны.

Это во-первых. Но в-нулевых, я не понимаю, по какой причине вы перескочили на подсчёт опубликованных уязвимостей в линуксе и OpenBSD.

Во-вторых, считаете уязвимости - считайте их для ядер с PaX/Grsecurity. Нет такой статистики? Ну, если для вас это повод сравнивать что попало... Даже не знаю, стоит ли возражать.

> В OpenBSD оно с каждым годом стремительно уменьшается. Вы, конечно, можете
> крикнуть: "потому что скрывают!". Но я пока не видел этому подтверждений,

Кстати, да. Скрывают. Но ненамеренно - в рамках обычного процесса исправления ошибок в коде. Об этом вы даже можете прочитать здесь: http://www.openbsd.org/security.html

In most cases we have found that the determination of exploitability is not an issue. During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable.

В линуксе, кстати, тоже скрывают - и намеренно. Отвратительная практика! Не знаю, может быть, вы уже записали меня в пингвинопоклонники, но будь полный аналог PaX в какой-нибудь Net/FreeBSD, я перешёл бы на неё с искренней радостью. Благо, в функциональность и скорость работы этих ОС для решения моих задач меня вполне устраивают (в отличие, к сожалению, от опёнка).

> хотя честно читаю source-changes@, и разглядываю все настораживающие коммиты.

А толку-то? Что вы там собираетесь увидеть, если даже разработчики в security.html написали, что не всегда различают эксплуатабельность багов - прямо как для вас же писали, делайте выводы! :)

> Какое заблуждение? Вы вообще о чём? О том, что изоляция привилегий полезна?

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

> Я не пойму, вы на пару с этим товарищем не понимаете,
> против чего вообще эта защитная мера нужна, что ли? Ядро она
> не защищает, да, ну так и доклад-то был не "защитные техники
> ядра OpenBSD", не? Каша у вас какая-то.

А что, ядро в системе своей жизнью живёт? И в случае компрометации непривилегированного процесса вообще ни при чём?

>> По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или
>> наоборот.
> Это ортогональные вещи, почему г-н Альбертс сплёл их вместе - только ему
> и известно.

Это звенья одной цепи. Одной! Не разные уровни защиты, понимаете? Вот меры предотвращения экслпуатации и меры смягчения последствий эксплуатации - вещи действительно ортогональные.

>> Не вижу. Обсуждаем звенья одной цепи.
> Да, но РАЗНЫЕ звенья. Вот вам цепь, пять звеньев. Первое, второе и
> третье держат до 50 ньютонов, четвёртое до 30, пятое до 20.
> Усилили пятое, теперь оно тоже держит 50 ньютонов. Вопль со стороны:
> "да нафига делали, всё равно порвётся". Цена этому воплю знаете, какая?

А где эти намерения поработать над четвёртым? Я даже не спрашиваю, где они в презентации - ответьте, где они в принципе декларированы? Где, мать жеж перемать, хотя бы место этому звену в модели угроз и их противодействия? Ну усилили они пятое звено много лет назад, ТОЛКУ ТО?

Пришли же потом люди и взломали ядро дважды (включая локальную уязвимость). А не реализуй, наконец-то, разработчики запрета на маппинги по нулевому адресу (с многолетним опозданием после PaX/Grsecurity), уязвимости было бы три - это всё есть в вашей любимой эррате. Где же ваше соотношение 20/30? Где цифры, где факты? Ещё раз: одна уязвимость в OpenSSH против двух в ядре. При этом уж что-что, а OpenSSH пользуется гораздо большей популярностью, чем опен - в раз, эдак... на несколько порядков - и цели защищает гораздо более многочисленные и привлекательные.

>> Этот "софизм" совпадает с моими собственными выводами.
> Печально.

Не это печально, поверьте мне...

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

114. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle (ok) on 28-Сен-11, 09:52 
> В линуксе, кстати, тоже скрывают - и намеренно. Отвратительная практика! Не знаю,
> может быть, вы уже записали меня в пингвинопоклонники, но будь полный
> аналог PaX в какой-нибудь Net/FreeBSD, я перешёл бы на неё с
> искренней радостью.

Люди, занимающиеся безопасностью в NetBSD, с большим уважением относятся
к проекту grsecurity и его авторам. Цитировать частную переписку я не буду,
но если есть интерес, пообщайся с elad@ и christos@. Уверен, ответят
на все вопросы. Я далеко не безопастник, но securechroot взял именно из grsecurity.
Если есть интерес,
можешь поднять интересующие вопросы в tech-security@ или tech-kern@.
Список, уже реализованного я дал, многое взято опять же из grsecurity,
если чего-то не хватает, можно реализовать
самому ;-) или хотя бы отправить PR с описанием того, что хочется.

Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

129. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 29-Сен-11, 04:17 
Интерес есть, но этого мало, пока среди разработчиков нет ни одного высококлассного специалиста, который бы активно занимался сугубо вопросами безопасности в направлении, которое бы соответствовало моим ожиданиям. А сам я, к сожалению, не обладаю достаточной квалификацией.
Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

130. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 29-Сен-11, 12:37 
> Интерес есть, но этого мало, пока среди разработчиков нет ни одного высококлассного
> специалиста, который бы активно занимался сугубо вопросами безопасности в направлении,
> которое бы соответствовало моим ожиданиям.

Вот это да. Сделать такие выводы даже не познакомившись
и не пообщавшись с народом. :-/
Я не утверждаю, что elad@ - Гуру #1 в этом деле, но чтобы вот так...

> А сам я, к сожалению, не
> обладаю достаточной квалификацией.

Да, кусты были совсем рядом. Ну да ладно.

Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

132. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 29-Сен-11, 12:59 
> Я не утверждаю, что elad@ - Гуру #1 в этом деле, но
> чтобы вот так...

Зря вырываете слова из контекста. Будь он хоть трижды гуру, работает он не в том направлении (даже если и занят сугубо безопасностью, в чём я, по простоте своей, заранее сильно сомневаюсь). Иначе бы в NetBSD первым делом не kauth и усиленный chroot появились, а аналоги KERNEXEC, UDEREF или та же защита для юзерспейса.

> Да, кусты были совсем рядом. Ну да ладно.

Не понял метафоры.

Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

133. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 29-Сен-11, 13:32 
>> Я не утверждаю, что elad@ - Гуру #1 в этом деле, но
>> чтобы вот так...
> Зря вырываете слова из контекста. Будь он хоть трижды гуру, работает он
> не в том направлении (даже если и занят сугубо безопасностью, в
> чём я, по простоте своей, заранее сильно сомневаюсь). Иначе бы в
> NetBSD первым делом не kauth

http://www.stihi-rus.ru/1/Mayakovskiy/66.htm

Функции kauth в другом, совсем в другом.

> и усиленный chroot появились,

Я не специалист по безопасности, и не претендую,
мне вот ЭдАк захотелось, я себе сделал.

> а аналоги
> KERNEXEC, UDEREF

URL на описание KERNEXEC?

> или та же защита для юзерспейса.

WTF?

Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

134. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 29-Сен-11, 14:12 
> http://www.stihi-rus.ru/1/Mayakovskiy/66.htm

Не понимаю, к чему. Давайте без намёков.

> Функции kauth в другом, совсем в другом.

В другом по сравнению с чем?

Если разработчикам удобнее раньше начать, раньше закончить фреймворк и писать под него модули, параллельно укрепляя защиту ядра, я не возражаю, но у меня свои задачи и приоритеты, которые диктуют выбор ОС. Мне в первую очередь нужна защита угроз, актуальных уже сегодня.

> Я не специалист по безопасности, и не претендую,
> мне вот ЭдАк захотелось, я себе сделал.

То есть, это вы портировали chroot restrictions в NetBSD?

> URL на описание KERNEXEC?

Аналог W^X для ядра. Документации, к сожалению, нет. Есть код и описание опции:
This is the kernel land equivalent of PAGEEXEC and MPROTECT,
that is, enabling this option will make it harder to inject
and execute 'foreign' code in kernel memory itself.

>> или та же защита для юзерспейса.
> WTF?

Полный W^X, полный ASLR (с поддержкой PIE и защитой от брутфорса), запрет на запись в GOT, а также возможность запретить PROT_EXEC|PROT_WRITE маппинги и mprotect. На сколько я понял из доков, пока есть только порт PaX MPROTECT и, видимо, частичный W^X (иначе зачем MPROTECT), который не документирован.

Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

136. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 29-Сен-11, 14:59 
>> Функции kauth в другом, совсем в другом.
> В другом по сравнению с чем?

kauth - не для зашиты от rootkit-ов, а для реализации
кастомных политик бьезопасности.

> То есть, это вы портировали chroot restrictions в NetBSD?

Не портировал, а реализовал аналог, глядя на описание на сайте.
Но закоммитить мне его не дали.
Отправили на доработку, хотя мне не очень ясно, на какую именно.
Будет время -- займусь, пора другие погремушки отвлекают.

>>> или та же защита для юзерспейса.
>> WTF?
> Полный W^X,

http://www.netbsd.org/docs/kernel/non-exec.html
Оно?

> полный ASLR

ASLR есть, урл на ман я давал. Включаемы/Выключаемый per executable или глобально.
По умолчанию выключен.

> (с поддержкой PIE

PIE есть, надо глянуть, как собираются sshd и другие в базовой системе.
По умолчанию PIE в компиляторе выключен.
Установки на сборку демонов в pkgsrc с PIE в обязательном порядке нет.

> и защитой от брутфорса),

security(7)
/ PaX Segvguard
Не?

> запрет на запись в GOT,

Вроде этого нет, но лучше спросить в рассылках.

> а также возможность запретить PROT_EXEC|PROT_WRITE маппинги и mprotect.

Запретить каким образом? URL?

> На сколько я понял из доков, пока есть только порт
> PaX MPROTECT и, видимо, частичный W^X (иначе зачем MPROTECT), который не
> документирован.

mprotect(2) ?

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

137. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 29-Сен-11, 18:10 
> kauth - не для зашиты от rootkit-ов, а для реализации
> кастомных политик бьезопасности.

О руткитах речи не шло. Наличие в системе руткита - следствие её полной компрометации, меры избежания которой я и считаю наиболее важными. Я понимаю, что такое kauth и зачем он нужен. И с практической точки зрения он бесполезен, пока ядро не защищено - по той же причине, по которой бесполезно разделение привилегий: https://www.opennet.ru/openforum/vsluhforumID3/80467.html#102

> Не портировал, а реализовал аналог, глядя на описание на сайте.
> Но закоммитить мне его не дали.

Ага, ясно. Не обратил внимание, что вы дали ссылку на RFC. Что ж, успехов (без иронии)!

> http://www.netbsd.org/docs/kernel/non-exec.html
> Оно?

Оно, спасибо. Поддержка i386 очень огорчает, потому что реализовать полноценный аналог UDEREF можно только на этой архитектуре (из распространённых).

>> полный ASLR
> ASLR есть, урл на ман я давал. Включаемы/Выключаемый per executable или глобально.

Да, я видел. Вопрос в полноте. Обязательно посмотрю на досуге. Ссылку на W^X вы не сразу дали, а сам я поленился поискать. В сумме уже неплохо.

> По умолчанию выключен.

Зря. Маргинализация тех или иных функций обычно плохо сказывается на качестве реализации и поддержки. В случаях с защитой - особенно.

> По умолчанию PIE в компиляторе выключен.
> Установки на сборку демонов в pkgsrc с PIE в обязательном порядке нет.

Зря. Проблемы с поддержкой в дебаггере? Как минимум на amd64 у PIE не должно быть проблем с регистрами и производительностью.

>> и защитой от брутфорса),
> security(7)
> / PaX Segvguard
> Не?

Не совсем. Кроме SIGSEGV нужно "отслеживать" SIGBUS и SIGILL, а также, возможно, SIGKILL (зависит от того, использует ли ядро этот сигнал для убийства процессов за несанкционированные действия). В Grsecurity это сделано проще и без рисков исчерпания памяти ядра: если дочерний процесс умирает по одному из упомянутых сигналов, в task_struct->brute родительского процесса пришется единица, по наличию которой включается 30-секундная задержка при создании потомков. К слову о названии "PaX Segvguard": в оригинальном PaX защита от брутфорса отсутствует, она добавлена именно в Grsecurity (опция GRKERNSEC_BRUTE).

>> а также возможность запретить PROT_EXEC|PROT_WRITE маппинги и mprotect.
> Запретить каким образом? URL?

Это уже сделано в "PaX Mprotect". В ответ на попытку совместить эти флаги в mmap и mprotect возвращается ошибка.

>> На сколько я понял из доков, пока есть только порт
>> PaX MPROTECT и, видимо, частичный W^X (иначе зачем MPROTECT), который не
>> документирован.
> mprotect(2) ?

PaX MPROTECT, заглавными. В оригинальном PaX и вашем security(8) он так и называется. "Не документирован" - это в адрес W^X: добавить пару слов о нём в security(8) не помешало бы.

Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

138. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 29-Сен-11, 19:00 
> https://www.opennet.ru/openforum/vsluhforumID3/80467.html#102

Повторять не надо, я не глухой и не слепой ;-)
Но "kauth(9) - бесполезен" мы обсуждать все-таки не будем.

>> ASLR есть, урл на ман я давал. Включаемы/Выключаемый per executable или глобально.
>> По умолчанию выключен.
> Зря.

Ну, в целом разработчики здесь действительно (так, чтоб прямо ВСЕ)
не бегают с плакатами "безопасность, безопасность, безопасность!".
Включение SSP по умолчанию, например, вызвало в свое время ругань на добрую сотню
сообщений в рассылке. Пятипроцентное замедление народ не устроило.
Но у админа ручки-крутелки есть. То же касается
ключей сборки системы.
https://www.opennet.ru/openforum/vsluhforumID3/80467.html#98
Здесь вся система делается одной командой. Пару строк в mk.conf
и всего делов.

> Маргинализация тех или иных функций обычно плохо сказывается на качестве реализации
> и поддержки. В случаях с защитой - особенно.

Есть такое дело, pkgsrc-ый emacs22 падает в корку, например.

>> По умолчанию PIE в компиляторе выключен.
>> Установки на сборку демонов в pkgsrc с PIE в обязательном порядке нет.
> Зря. Проблемы с поддержкой в дебаггере? Как минимум на amd64 у PIE
> не должно быть проблем с регистрами и производительностью.

Не в курсе.

> "Не документирован" - это в адрес W^X: добавить пару слов
> о нём в security(8) не помешало бы.

Да, согласен. Надо народ пошевелить.

Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

135. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 29-Сен-11, 14:21 
http://pax.grsecurity.net/docs/index.html - здесь документация по PAGEEXEC, MPROTECT и не только.
Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

139. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 30-Сен-11, 21:24 
>> будет известно. Хреново.

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

>> Если не стоковое, то нужна не просто утечка,
>> а из данного системного вызова. Две разных уязвимости на один системный
> Уязвимость к утечке может быть где угодно. Главное, чтобы утечка произошла с
> адреса на общем стеке, где лежит canary-значение, сохранившееся после предыдущего сисколла.

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

Другое дело, что возможность считать произвольный адрес в памяти несёт в себе столько потенциальных угроз (вроде считывания ключей IPSec), что в гроб ложиться можно сразу. Так что я бы не стал заморачиваться утаиванием канарейки, а обратил внимание в первую очередь на исходную проблему (возможности считывания), как более актульную. Тем более, что никакой дополнительный слой защиты от таких ошибок не спасёт: как он отличит легальное обращение к, скажем, контексту процесса от нелегального?

>> В вашем ненаглядном PaX, как я понимаю, дела обстоят лучше? Что там
>> генерится?
> Лучше, но, во-первых, лишь с недавнего времени,

:-P

> а во-вторых, PaX не имеет никакого отношения к SSP.

Ну, да, прошу прощения, имелось в виду что сделано касаемо отлавливания ошибок с переполнением буфера в рамках проектов PaX/GrSecurity.

> Так вот, с недавнего времени для предотвращения
> утечек со стека PaX Team разработал плагин для GCC >= 4.5,
> который зануляет стек сисколлов перед использованием. Правда, не целиком, а на
> базе эвристики - иначе, оверхед слишком велик.

Зануление лишь уменьшит окно, но не спасёт на 100%: атакующему достаточно считать значение (канарейки, или что там ещё вкусное будет) на стеке во время работы соответствующего системного вызова, и делать ему это в любом случае надо из другого потока выполнения. Так что эффективность этой меры не больше, чем у того же SSP. ;) Кстати, в документации PaX написано то же самое, про неполную эффективность.

>> А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся
>> в том же PaX технологий?
> Я могу сказать, что эксплуатацию через userland pointer dereference PaX останавливает на
> 100% на x86, с высокой вероятностью на amd64 (требуется утечка памяти
> для обхода защиты)

Имеется в виду именно выполнение кода по указанному адресу в области данных пользовательского процесса, как я понимаю? Или PaX как-то отлавливает несанкционированные чтение-запись?

А передача управления на исполняемый код пользовательского процесса? На область стека?

> а NULL pointer dereference (подкласс предыдущего класса) останавливает
> везде, благодаря обычному уже запрету на маппинги по нулевому адресу (код
> которого, кстати, давно включён в апстрим).

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

> Эксплуатацию через возврат на данные в памяти ядра, как в случае IPv6-уязвимости
> в OpenBSD, PaX останавливает на 100%.

На любой платформе?

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

> Утечки памяти при её выделении юзерспейсу - на 100%.

Хм. Я-то думал, такое из популярных ОСей только в винде бывает (как сейчас - не знаю, а в WinXP и ранее память после TerminateProcess() утекала точно).

>[оверквотинг удален]
> - процент назвать не берусь, но общее мнеие, что USERCOPY весьма
> эффективен в этом.
> Если коротко, то почти все уязвимости, которые были упобликованы для линукса, либо
> невозможно (не считая DoS-эффекта - тут линукс в аутсайдерах), либо значительно
> сложнее эксплуатировать на PaX-ядрах, за исключением редчайших случаев arbitrary read+write
> или более частых утечек + arbitrary write (при некотором везении).
>> Ошибка (не столько техническая - назвать страуса павлином, - сколько логическая, да)
> Логическая ошибка - это упорно назвать ядро ядром, с такой коннотацией, будто
> оно и не процесс вовсе, и защищать его нужно отдельно от
> остальных процессов и хранимых данных.

Вы меня вообще не слышите, что ли? Я говорю, что помимо ядра есть и другие процессы. И что защищать надо НЕ ТОЛЬКО ядро. А вы себе, получается, противоречите: когда речь идёт о защите ядра, то вы возмущаетесь, когда не все меры сразу принимаются; а когда этот же принцип обобщается на все процессы, то вы уже пытаетесь доказать, что этим заниматься нет смысла.

> Принцип, за который вы так уцепились, строго говоря, в ОС вроде OpenBSD,
> линукса и им подобным воплотить невозможно по определению этого самого принципа.

За какой принцип? Что не надо думать односторонне? Вроде бы вы то же самое говорите. Только как-то избирательно.

> Однако к умалчиванию такого "нюанса" у вас претензий нет, зато есть
> масса скепсиса по отношению к квалификации человека, о которой вы не
> имеете даже концептуального представления, достаточно близкого к полному.

"Масса"? Я привёл пример. Очевидный для любого человека, который умеет складывать 2 и 2. А вы не то занимаетесь подтасовкой и передёргиванием (не хочу в это верить, но допускать такую возможность приходится), не то просто не видите противоречия.

>> в том, что он прямо говорит: "разделение привилегий бесполезно, так как
>> неуязвимых ядер не бывает". Простите, но это бред. Вы сами ниже
> Вы упорно игнорируете контекст сказанного. Следуя вашей интерпретации, PaX Team считает
> бесполезным и отделение суперпользователя от обычных пользователей, и MAC-системы в части
> функций, не ограничивающих доступ к ядру, и само разделение привилегий исполняемых
> страниц памяти - чего уж там, если компрометация непривилегированного процесса равносильна
> компрометации всей системы. For noone has a bugfree kernel же.

Моя интерпретация базируется на сказанном. Ваша - на якобы подуманном. Разницу чуете?

> Где те границы, не позволяющие довести мнение компетентного человека до абсолютного абсурда?
> Вы их стёрли, цепляясь к словам и утверждая, что контекст неважен.

Этот контекст не был напрямую озвучен. Было сказано (буквально!), что в разделении привилегий пользовательских приложений нет смысла, так как не бывает ядер ОС без изьянов. Это высказывание неверно изначально, безо всякого доведения до абсурда, так как оставляет за бортом класс уязвимостей, дающих root-доступ к ОС.

А если, по-вашему, автор текста хотел сказать на самом деле что-то другое, то почему бы он не хотел сказать что-то другое и по другим моментам, на которые вы напираете? Путём догадок можно и чёрное в белое превратить.

> Фактически, следуя вашей интерпретации, PaX Team в обзоре презентации говорит одно,
> а на деле занимается соврешенно противоположным, укрепляя защиту ядра от атак
> со стороны пользовательских процессов. Всё, включая факты и здравый смысл, противоречит
> вашей гипотезе. Единственное, что можно было бы утверждать, имея хоть какие-то
> основания - это то, что PaX Team слишком резко сказал сгоряча.
> Однако, сомнений в его хладнокровии я не слышал - только сомнения
> в квалификации.

То есть по чётным дням недели он специалист по безопасности, а по нечётным его нельзя слушать? Гениально.

> Если вам этих доводов мало, мне больше возразить нечего.

Ещё раз: ваши доводы базируются на ваших догадках, что хотели сказать. Мои - на том, что было сказано. Вы сами напираете на разработчиков OpenBSD, что, дескать, слова расходятся с фактами. А другим это, стало быть, простительно?

>> пишете, что, мол, "По моей логике, реализовав разделение привилегий, нужно браться
>> за усиление ядра, или наоборот". Вот, одну вещь сделали. Ваша (или,
>> по крайней мере, товарища Альбертса) претензия в том, что это не
> Вы спутали автора перепоста на bugtraq с PaX Team aka pipacs -
> он известен только под псевдонимами.

Прошу прощения.

>> произошло одновременно? Ну извините. Может, PaX/GrSecurity тоже за ночь появились? Или
>> напомнить об уязвимостях в самих этих защитных механизмах? Я не User294
> Претезния в том, что эти риски, обусловленные незащищённым ядром, не были даже
> упомянуты (!) в обсуждаемой презентации, а меры по их снижению (механизмы
> защиты ядра) не реализованы до сих пор, спустя почти семь лет
> (!), а вовсе не одну ночь.

А это уже совсем другой разговор.

Вообще говоря, я так и не понял, про какую презентацию была речь. Полагаю, она не сильно отличалась от, например, этой, опубликованной в примерно то же время: http://www.openbsd.org/papers/csw03/. И если б то, к чему я, по-вашему, безосновательно придрался, было единственным подобным моментом... Вот это, например:

"we learn that the buffer is ALWAYS at the same place. how nice. how secure. stuff like environment strings, program arguments and whatnot surely have no role in the stack pointer value. apparently not on OpenBSD. proactive insecurity, isn't it."

Что имелось в виду, мне, честно говоря, до конца не понятно. Допущение, что буфер будет в разных местах, оно усложняет жизнь атакующему, а не облегчает. Но разбирать-то надо наихудшие _для_защищающегося_ варианты. Взять какой-нибудь системный сервис из стоковой поставки, типа того же sshd: он наверняка будет запускаться в одинаковом окружении (ну разве что локаль разная) и с одинаковыми параметрами на многих, многих машинах. Но если автор слов из этой цитаты действительно крутой спец, то должен всё это понимать. Ну или хотя бы перед тем как кидаться обвинениями, заглянуть в исходный код, соответствующая логика в sys/kern/kern_exec.c не менялась как минимум с 01.01.2003.

Или вот:

"apparently on OpenBSD the top of the stack is what normal mortals consider the bottom of it".

Видимо, товарисч не знает, что на разных аппаратных платформах стек может расти в разные стороны. Что, правда, вполне ожидаемо от автора x86-only (изначально) патча. Вот ещё одно свидетельство оторванности от реальности:

"and you're wondering why other vendors haven't picked it up (one wonders where OpenBSD picked it up from). maybe because they can count further than 15. what about 24, or 32 or whatever the address space reasonably allows? sounds better, doesn't it."

Видимо, автор забыл, что на некоторых платформах и 256 КБайт памяти могут быть роскошью (к слову, значение этого лимита разное на разных платформах, на том же vax оно ещё меньше, например). Более того, в предыдущем абзаце автор удосужился уточнить: "(or more precisely, whatever our admin deemed acceptable for his sense of security)", но, видимо, к концу абзаца забыл об этом.

А вот о провидческом таланте, которым вы восхищались:

"here we are told that i386 is not all that bad provided one uses its 64 bit cousin and learns to program in PAE mode. apparently the latter is a serious challenge for the OpenBSD Team (read: they couldn't just lift the code from FreeBSD)."

Как я уже говорил в этой теме, PAE в OpenBSD таки появился. Ну и так далее...

> Об уязвимости - единственной - я и без вас помню.

Я просто к тому, что не могу припомнить уязвимостей, порождённых внедрением защитных технологий в OpenBSD. А если вы скажете, что, мол, одна уязвимость - с кем не бывает, так и я вам скажу, что две уязвимости в заметно большем количестве кода - с кем не бывает.

> Остальные уявзимости
> были найдены в изначальном коде ядра, и если поддавались эксплуатации, то
> в обход мер защиты PaX/Grsecurity, а не путём их отключения или
> нахождения недокументированного изъяна.

Угу. Правда, в OpenBSD все её защитные фичи есть, работают изначально и - прошу заметить - на всех платформах. В то время как PaX в mainstream так что-то и не идёт... Тот же Hardened Gentoo никто не отменял, согласен, но и софт не весь в нём работает, имеющийся в "обычном" варианте Gentoo, так ведь?

(Кстати, в ходе раскопок с удивлением узнал, что Ubuntu - по сути, единственный из mainstream-дистрибутивов Linux, где по умолчанию включён SSP)

>> и кричать epic fail по этому поводу не собираюсь, косяки у
>> всех бывают. Но как-то думать над тем, что пишешь, тоже надо.
>> Ну или отвечать за свои слова.
> Ну-ка, ну-ка!.. В свете упоминания ответственности за слова, у вас никаких претензий
> к разработчикам OpenBSD нет, *случайно*?

В обсуждаемом докладе была _ложь_? Упрёки в том, что в OpenBSD не было реализовано (или реализованно слабее) что-то, что уже было в PaX, я видел. Насмешки о (якобы) бесполезности тех или иных моментов видел. Понты видел. Утверждений о лжи не видел.

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

Да НИКТО не спорит с этим, в который раз уже говорю. Просто оно - не единственный процесс в системе. Защищать ядро надо? - надо. В первую очередь? - да. Но: следует ли игнорировать другие защитные механизмы и заниматься только ядром? - очевидно, нет.

>> Спасибо, кэп.
> Ну тогда я не понимаю, почему вам не нравится, что оспаривая состоятельность
> принципа разделения привилегий, я указываю на изъяны в ядре. Совершенно не
> понимаю.

Потому что одно не отменяет другого. Если у вас (хакера) есть два врага, Вася (ядро) и Петя (обычный процесс), и на Пете есть бронежилет, которого нет на Васе, это ещё не 100% гарантия, что Вася сдастся раньше Пети. Здесь можно вести речь лишь о вероятностях.

>> Я не люблю строить догадки, кто что имел в виду. Есть конкретные
> А знаете, что? IRC-сеть OFTC, канал #pax, ник pipacs - выскажите ваши
> вопросы и сомнения непосредственно виновнику торжества непонимания. Что мы, действительно,
> догадки сторим...
>> слова: "privilege revocation does actually make sense however privilege separation (not
>> seperation) doesn't. for noone has a bugfree kernel". Если он хотел
>> сказать что-то другое - сочувствую, конечно, но подтверждений этому не вижу.
> Так сходите и найдите. Дело пяти минут. Не застанете его на канале
> - ну так держать Xchat в трее до поры тоже не
> накладнее, чем тратить время на комментарии здесь. Ага?

У меня вопросов и сомнений нет. Догадки (что было сказано) есть у вас. Вы утверждаете, что автор текста имел в виду не то, что им написано - вам это и доказывать, не?

Ну а если вы считаете, что ничего доказывать не надо, предлагаю разойтись по этому пункту. Всё равно никто никого не убедит. :)

>> Я смотрю на количество errata в ядре Linux и ядре OpenBSD, например.
> Я вам ещё одно количественное сравнение предлагаю: назвать хотя бы одного (!)
> эксперта в области безопасности, котороый бы входил в команду разработчиков OpenBSD
> или хотя бы сотрудничал с ними на более-менее постоянной основе. Это
> я кагбе намекаю на косвенное следствие из разницы в популярности двух
> ОС и "шарма" Тео и ко. в вопросах привлечения людей со
> стороны.

А экспертов в области безопасности по какому принципу отбирать? Как работавших над PaX/GrSecurity или как не работавших над OpenBSD? ;)

> Это во-первых. Но в-нулевых, я не понимаю, по какой причине вы перескочили
> на подсчёт опубликованных уязвимостей в линуксе и OpenBSD.

По простой: сравнить эффективность подхода к безопасности в OpenBSD и Linux спустя те самые восемь лет не в теории, а на фактах.

> Во-вторых, считаете уязвимости - считайте их для ядер с PaX/Grsecurity. Нет такой
> статистики? Ну, если для вас это повод сравнивать что попало... Даже
> не знаю, стоит ли возражать.

Maintream с mainstream'ом, это "что попало"? Впрочем, жду ваших цифр. Мои цифры таковы: Для OpenBSD 4.9 (то есть полгода с момента выхода релиза) errata ПУСТАЯ. Ну, не нашлось ничего, что тянуло хотя бы на проблему надёжности вообще.

>[оверквотинг удален]
> not an issue. During our ongoing auditing process we find many
> bugs, and endeavor to fix them even though exploitability is not
> proven. We fix the bug, and we move on to find
> other bugs to fix. We have fixed many simple and obvious
> careless programming errors in code and only months later discovered that
> the problems were in fact exploitable.
>> хотя честно читаю source-changes@, и разглядываю все настораживающие коммиты.
> А толку-то? Что вы там собираетесь увидеть, если даже разработчики в security.html
> написали, что не всегда различают эксплуатабельность багов - прямо как для
> вас же писали, делайте выводы! :)

Вот поэтому и разглядываю. Как разглядывал бы в любой другой ОС, которая была бы основным полем интересов. ;)

>> Какое заблуждение? Вы вообще о чём? О том, что изоляция привилегий полезна?
> О том, что принцип разделения привилегий может быть реализован как-либо в отрыве
> от обеспечения безопасности ядра.

Нужно и то, и другое. С этим-то хотя бы вы согласны?

>> Я не пойму, вы на пару с этим товарищем не понимаете,
>> против чего вообще эта защитная мера нужна, что ли? Ядро она
>> не защищает, да, ну так и доклад-то был не "защитные техники
>> ядра OpenBSD", не? Каша у вас какая-то.
> А что, ядро в системе своей жизнью живёт? И в случае компрометации
> непривилегированного процесса вообще ни при чём?

Может, причём. А, может, и нет. Если для злоумышленника нет доступной уязвимости в ядре, ему хватит и просто рутовых прав. Поэтому источник проблем в виде процесса с рутовыми правами надо ТОЖЕ прикрывать.

>[оверквотинг удален]
>> Да, но РАЗНЫЕ звенья. Вот вам цепь, пять звеньев. Первое, второе и
>> третье держат до 50 ньютонов, четвёртое до 30, пятое до 20.
>> Усилили пятое, теперь оно тоже держит 50 ньютонов. Вопль со стороны:
>> "да нафига делали, всё равно порвётся". Цена этому воплю знаете, какая?
> А где эти намерения поработать над четвёртым? Я даже не спрашиваю, где
> они в презентации - ответьте, где они в принципе декларированы? Где,
> мать жеж перемать, хотя бы место этому звену в модели угроз
> и их противодействия? Ну усилили они пятое звено много лет назад,
> ТОЛКУ ТО?
> Пришли же потом люди и взломали ядро дважды (включая локальную уязвимость).

Дважды за десять с лишним лет, да. (см. выше)

> А не реализуй, наконец-то, разработчики запрета на маппинги по нулевому адресу (с
> многолетним опозданием после PaX/Grsecurity), уязвимости было бы три - это всё
> есть в вашей любимой эррате.

Тем не менее, реализовали вовремя. "Если бы да кабы, да росли во рту грибы..." Вы пишете так, как будто жалеете, что разработчики OpenBSD это сделали, и что не схлопотали ещё одну 0-day уязвимость.

> Где же ваше соотношение 20/30?

Навскидку из сделанного в ядре с того момента - улучшили рандомизацию адресного пространства, ужесточили контроль над памятью при вводе-выводе, добавили и, разумеется, начали использовать опции GCC (-Wstack-larger-than-N, -Wbounded, -Wvariable-decl; описаны в gcc-local(1): http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&sekti... )...

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

Правильно, и поэтому код OpenSSH исследует больше людей, чем код ядра OpenBSD. Да и по объёму кода они отличаются в более чем сорок раз: 2,5 мегабайта против 106. Вот вам и цифры. А если учесть ещё и тот факт, что с возрастанием количества кода, количество потенциально уязвимых мест возрастает отнюдь не линейно...

Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

140. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от paxuser (ok) on 02-Окт-11, 07:14 
> вызовов в случае ядра). Впрочем, для её считывания всё равно надо
> иметь возможность читать более-менее произвольную область памяти. (см. ниже)

Для её считывания достаточно утечки неинициализированной переменной или неинициализированной области выравнивания полей структуры.

Вы не знаете об этом или не рассматриваете по каким-то другим причинам?

Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

142. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от paxuser (ok) on 02-Окт-11, 12:20 
> Не совсем понял фразы "общий стек": для каждого потока выполнения в ядре
> свой стек. Но добраться до этого стека при условии, что мы

Имелся ввиду общий стек системных вызовов.

> Другое дело, что возможность считать произвольный адрес в памяти несёт в себе
> столько потенциальных угроз (вроде считывания ключей IPSec), что в гроб ложиться
> можно сразу. Так что я бы не стал заморачиваться утаиванием канарейки,

"Чтение произвольного адреса" бывает разным - это может быть и off-by-one, и частично подконтрольное атакующему значение смещения относительно указателя, и целочисленное переполнение не более, чем на некоторую величину. Уязвимостей к абсолютно случайному чтению существует гораздо меньше, чем к ограниченному.

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

В течение недели PaX Team планирует выпустить плагин для GCC, который позволяет бороться c целочисленным переполнением в случаях, когда точно известно, что оно нежелательно. В частности, в случае переполнения размера буфера, передаваемого в юзерспейс посредством copy_from_user.

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

>> Лучше, но, во-первых, лишь с недавнего времени,
> :-P

А в OpenBSD и до сих ничего не сделано, и не только это. Перемен (даже тех, которые актуальны для борьбы с продемонстрированными способами атак) можно годами ждать и не дождаться.

>> Так вот, с недавнего времени для предотвращения
>> утечек со стека PaX Team разработал плагин для GCC >= 4.5,
>> который зануляет стек сисколлов перед использованием. Правда, не целиком, а на
>> базе эвристики - иначе, оверхед слишком велик.
> Зануление лишь уменьшит окно, но не спасёт на 100%: атакующему достаточно считать

Как я сказал в начале, уязвимость к произвольному чтению - не единственный способ получить что-либо со стека.

> значение (канарейки, или что там ещё вкусное будет) на стеке во
> время работы соответствующего системного вызова, и делать ему это в любом
> случае надо из другого потока выполнения. Так что эффективность этой меры

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

> не больше, чем у того же SSP. ;) Кстати, в документации
> PaX написано то же самое, про неполную эффективность.

Вы сравниваете эффективность меры защиты от эксплуатации линейных переполнений с эффективностью защиты от утечек - яблоки с апельсинами.

>>> А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся
>>> в том же PaX технологий?
>> Я могу сказать, что эксплуатацию через userland pointer dereference PaX останавливает на
>> 100% на x86, с высокой вероятностью на amd64 (требуется утечка памяти
>> для обхода защиты)
> Имеется в виду именно выполнение кода по указанному адресу в области данных
> пользовательского процесса, как я понимаю? Или PaX как-то отлавливает несанкционированные
> чтение-запись?

Нет, любое стандартное обращение по указателю: на чтение и запись тоже.

> А передача управления на исполняемый код пользовательского процесса? На область стека?

Предотвращается на 100% посредством KERNEXEC.

> Запрет на отображение по нулевому адресу в OpenBSD есть, и, прошу заметить,
> не отключается никакими переменными.

Я знаю, что есть, и уже говорил об этом.

>> Эксплуатацию через возврат на данные в памяти ядра, как в случае IPv6-уязвимости
>> в OpenBSD, PaX останавливает на 100%.
> На любой платформе?

На x86, amd64, 64-битных SPARK'ах и ARM - практически взеде, где есть та или иная аппаратная поддержка запрета на выполнение кода на заданных страницах/сегментах/регионах.

>> Утечки памяти при её выделении юзерспейсу - на 100%.
> Хм. Я-то думал, такое из популярных ОСей только в винде бывает (как
> сейчас - не знаю, а в WinXP и ранее память после
> TerminateProcess() утекала точно).

Утечки данных с освобождённой памяти встречаются повсеместно. А что, в OpenBSD зануляется абсолютно вся память перед выделением в юзерспейс?

> Вы меня вообще не слышите, что ли? Я говорю, что помимо ядра
> есть и другие процессы. И что защищать надо НЕ ТОЛЬКО ядро.

Я вас слышу и понимаю. Постарайтесь и вы понять.

> А вы себе, получается, противоречите: когда речь идёт о защите ядра,
> то вы возмущаетесь, когда не все меры сразу принимаются; а когда

Возмущают меня только двойные стандарты и дезинформация, которую разработчики OpenBSD распространяют среди её потенциальных и фактических пользователей. На остальное я лишь указываю в качестве аргументов или просто для информации.

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

Ничего подобного. Вы сейчас свалили в кучу защиту вообще и защиту в частности, меры предотвращения эксплуатации и меры смягчения её последствий. Разницу и границу между этими вещами я не стирал и более того: уже не единожды явно обозначил.

В первом ответе лично вам я сказал:

"Смысл в разделении привилегий существует только при условии надлежащей защиты ядра. Спорить на эту тему можно только с неуловимыми джо, однако презентация явно рассчитана не только на них."

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

> За какой принцип? Что не надо думать односторонне? Вроде бы вы то
> же самое говорите. Только как-то избирательно.

Принцип разделения привилегий.

> "Масса"? Я привёл пример. Очевидный для любого человека, который умеет складывать 2

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

> и 2. А вы не то занимаетесь подтасовкой и передёргиванием (не
> хочу в это верить, но допускать такую возможность приходится), не то
> просто не видите противоречия.

Подтасовкой чего? Передёргиваете вы - именно ваши выводы не согласуются с фактами.

> Моя интерпретация базируется на сказанном. Ваша - на якобы подуманном. Разницу чуете?

Ваша интерпретация базируется на сказанном, выдранном из контекста, и противоречит фактам. Моя - согласуется с фактами и сделана на базе факта несоблюдения принципа разделения привилегий в рамках данной его конкретной реализации. Чуете разницу?

Вы просто взяли и скинули за борт весь багаж достижений PaX Team - фактов, которым противоречит ваше толкование. Я вам указал на противоречия, и что в итоге? Вы на них ответили абстрактным постулатом об очевидности "примера" и подозрениями меня в передёргивании (согласно словарному определению: искажении фактов).

Вы считаете указанные противоречия ложными?

> Этот контекст не был напрямую озвучен. Было сказано (буквально!), что в разделении

Контекст часто не озвучен напрямую. Уж точно чаще, чем озвучен. В данном случае моё описание контекста хоть и является догадкой, но согласуется с фактами. В отличие от вашего буквального толкования.

> привилегий пользовательских приложений нет смысла, так как не бывает ядер ОС
> без изьянов. Это высказывание неверно изначально, безо всякого доведения до абсурда,
> так как оставляет за бортом класс уязвимостей, дающих root-доступ к ОС.

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

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

> А если, по-вашему, автор текста хотел сказать на самом деле что-то другое,
> то почему бы он не хотел сказать что-то другое и по

А какие у вас основания полагать, будто он где-то хотел сказать что-то другое? У меня их нет (в контексте моего понимания смысла сказанного, без видимых противоречий фактам).

> другим моментам, на которые вы напираете? Путём догадок можно и чёрное
> в белое превратить.

Именно этим вы и занимаетесь. Вырвали фразу из контекста и придрались к самой буквальной трактовке - да этот приём стар, как цивилизованный мир!

> То есть по чётным дням недели он специалист по безопасности, а по
> нечётным его нельзя слушать? Гениально.

Сделать из доводов собеседника абсурдные выводы и прокомментировать их, как точку зрения собеседника - тоже старый приём. Вам полемики захотелось? А ведь "гениальный" вывод, который вы озвучили, следует из вашей же трактовки смысла обсуждаемой цитаты. Действительно, гениально. ;)

> Ещё раз: ваши доводы базируются на ваших догадках, что хотели сказать. Мои
> - на том, что было сказано. Вы сами напираете на разработчиков

Как я указал выше, ваши доводы также базируются на догадках о значении слова "смысл" (sense).

> OpenBSD, что, дескать, слова расходятся с фактами. А другим это, стало
> быть, простительно?

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

> А это уже совсем другой разговор.

Нет. Как это относиться к теме обсуждения я уже пояснил.

> то же время: http://www.openbsd.org/papers/csw03/. И если б то, к чему я,

http://www.openbsd.org/papers/ven05-deraadt/

> по-вашему, безосновательно придрался, было единственным подобным моментом... Вот это,
> например:
> "we learn that the buffer is ALWAYS at the same place. how

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

А у вас есть сомнения в том, понимает ли? Любопытно, что для человека, который так ценит буквальный смысл в словах, вы обошли вниманием капитель в слове ALWAYS. ;) Присмотритесь к слайду, о котором шла речь:

http://www.openbsd.org/papers/ven05-deraadt/mgp00005.html

> Ну или хотя бы перед тем как кидаться обвинениями, заглянуть в
> исходный код, соответствующая логика в sys/kern/kern_exec.c не менялась как минимум с
> 01.01.2003.

Какими обвинениями?

> "apparently on OpenBSD the top of the stack is what normal mortals
> consider the bottom of it".
> Видимо, товарисч не знает, что на разных аппаратных платформах стек может расти
> в разные стороны. Что, правда, вполне ожидаемо от автора x86-only (изначально)
> патча. Вот ещё одно свидетельство оторванности от реальности:

Видимо? Ах, какое смелое допущение! А как же буквальный смысл? Вы его разлюбили? ;)

Алсо, на этот раз вы перегнули, придираясь к словам: стек растёт вниз на большинстве архитектур и на всех наиболее распространённых. Видимо, разработчики OpenBSD большие любители экзотики, что невзначай выражается даже в презентациях. ;)

> "and you're wondering why other vendors haven't picked it up (one wonders
> where OpenBSD picked it up from). maybe because they can count
> further than 15. what about 24, or 32 or whatever the
> address space reasonably allows? sounds better, doesn't it."
> Видимо, автор забыл, что на некоторых платформах и 256 КБайт памяти могут

256 килобайт адресного пространства? Это где, на микроконтроллерах? ;) У меня есть другая гипотеза (согласуется с фактами, почерпнутыми из других ваших сообщений): вы, возможно, забыли разницу между объёмами доступной физической памяти и адресным пространством виртуальной, на базе которого реализован ASLR.

> быть роскошью (к слову, значение этого лимита разное на разных платформах,
> на том же vax оно ещё меньше, например). Более того, в

Ох уж эта любовь к экзотике! :) Так и вижу, картина маслом: "Разработчики OpenBSD ограничивают энтропию ASLR на всех платформах по верхней границе для одной из экзотических." ;)

> предыдущем абзаце автор удосужился уточнить: "(or more precisely, whatever our admin
> deemed acceptable for his sense of security)", но, видимо, к концу
> абзаца забыл об этом.

Видимо, очевидно, само-собой разумеется! :) Забыл потому что забыл. ;)

> А вот о провидческом таланте, которым вы восхищались:

Вы стихи не пишете? А прозу? Если нет, советую. В вас пропадает талант к художественному преувеличению. :)

> "here we are told that i386 is not all that bad provided
> one uses its 64 bit cousin and learns to program in
> PAE mode. apparently the latter is a serious challenge for the
> OpenBSD Team (read: they couldn't just lift the code from FreeBSD)."
> Как я уже говорил в этой теме, PAE в OpenBSD таки появился.

Вот только забыли упомянуть, что тогда его не было. И более того:
http://www.openbsd.org/papers/ven05-deraadt/mgp00018.html ;)

> Ну и так далее...

И тому подобное! А как же иначе. ;)

> Я просто к тому, что не могу припомнить уязвимостей, порождённых внедрением защитных
> технологий в OpenBSD. А если вы скажете, что, мол, одна уязвимость

А если не припомните, значит, их нет?

> - с кем не бывает, так и я вам скажу, что
> две уязвимости в заметно большем количестве кода - с кем не
> бывает.

Со всеми бывает. Вот только сути моих выводов и вопросов это не меняет.

> Угу. Правда, в OpenBSD все её защитные фичи есть, работают изначально и
> - прошу заметить - на всех платформах. В то время как

И что? Знаете, лично меня эти измерения не интригуют нисколько. Мне практическая сторона вопроса интересует. А на неё не влияет, что и где включено в патчах, а что по умолчанию.

> PaX в mainstream так что-то и не идёт... Тот же Hardened

И? Озвучьте же выводы. Или это такая риторика, которая должна обескуражить? :)

> Gentoo никто не отменял, согласен, но и софт не весь в
> нём работает, имеющийся в "обычном" варианте Gentoo, так ведь?

Не так. Весь софт работает. Если что-то не работает, это можно настроить без пересборки чело-либо - отключить мешающие защиты для данного конкретного бинарника. Опять же, не вижу, какое это имеет отношение к делу. Вот в OpenBSD из-за запрета на маппинги по нулевому адрему есть проблемы с некоторыми приложениями в Wine. А в PaX этот запрет можно отключить, и на защите UDEREF это никак не скажется.

> (Кстати, в ходе раскопок с удивлением узнал, что Ubuntu - по сути,
> единственный из mainstream-дистрибутивов Linux, где по умолчанию включён SSP)

Он включён практически во всех популярных дистрибутивах, короме дебиана. Просто где-то это -fstack-protector, а где-то - -fstack-protector-all.

>> Ну-ка, ну-ка!.. В свете упоминания ответственности за слова, у вас никаких претензий
>> к разработчикам OpenBSD нет, *случайно*?
> В обсуждаемом докладе была _ложь_? Упрёки в том, что в OpenBSD не

Ложью вы называете намеренную дезинформацию? Или дезинформация по незнанию, легкомыслию и по причине субъективно обоснованных упрощений тоже считается? А если не считается, то как по-вашему, нужно ли отвечать за такую дезинформацию как за слова? ;)

> было реализовано (или реализованно слабее) что-то, что уже было в PaX,
> я видел. Насмешки о (якобы) бесполезности тех или иных моментов видел.

Это где же это насмешки? :)

> Понты видел. Утверждений о лжи не видел.

Ссылку на понты покажете, или на слово вам поверить? ;)

> Да НИКТО не спорит с этим, в который раз уже говорю. Просто
> оно - не единственный процесс в системе. Защищать ядро надо? -
> надо. В первую очередь? - да.

Может быть, проясните тогда, почему безопасностью ядра в OpenBSD занялись в последнюю очередь?

> Но: следует ли игнорировать другие
> защитные механизмы и заниматься только ядром? - очевидно, нет.

Обратного я не утверждал. К чему эта полемика?

> Потому что одно не отменяет другого. Если у вас (хакера) есть два
> врага, Вася (ядро) и Петя (обычный процесс), и на Пете есть
> бронежилет, которого нет на Васе, это ещё не 100% гарантия, что
> Вася сдастся раньше Пети. Здесь можно вести речь лишь о вероятностях.

Ну, как показала практика, Петя таки сдался раньше Васи. В OpenSSH опубликовали уязвимость ещё до того, как были реализованы защиты юзерспейса и разделение привилегий (которое, кстати, на эксплуатируемость ошибок в коде практически не влияет - влияет только на его привилегии). В ядре с тех пор опубликовали 3 уязвимости, полная компрометация через две из которых предотвращается с помощью запрета на 0-маппинги.

> У меня вопросов и сомнений нет. Догадки (что было сказано) есть у

Зато у вас есть утверждения, которые, к тому же, не согласуются с фактами.

> вас. Вы утверждаете, что автор текста имел в виду не то,
> что им написано - вам это и доказывать, не?

Нет. Я утверждаю, что он имел ввиду не то, что вы решили, выдрав его фразу из контекста.

> Ну а если вы считаете, что ничего доказывать не надо, предлагаю разойтись

То есть, фразу из контекста выдрали вы, а доказывать, что не верблюд, должен я? :)

> по этому пункту. Всё равно никто никого не убедит. :)

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

> А экспертов в области безопасности по какому принципу отбирать? Как работавших над

Принципов нет. Признаки есть. Например, что является основным занятием или сколько времени уделяет человек работе над различными аспектами безопасности. Числятся ли за ним публикации, уникальные исследования или нетривиальные реализации способов защиты или нападения. Не самозванный ли он эксперт - имеет ли заслуженный авторитет в сообществе. И т.д., но этого, думаю, достаточно.

> PaX/GrSecurity или как не работавших над OpenBSD? ;)

Хехе.

> По простой: сравнить эффективность подхода к безопасности в OpenBSD и Linux спустя
> те самые восемь лет не в теории, а на фактах.

То есть, обсуждаем линукс с PaX/Grsecurity по сравнению с OpenBSD, а сравнивать вы предлагаете апстримный линукс? И противоречий в этом никаких не находите? :)

> Maintream с mainstream'ом, это "что попало"? Впрочем, жду ваших цифр. Мои цифры

А апельсины с яблоками вы тоже как фрукты с фруктами сравнивали бы? :) С практической точки зрения с безопасностью в мейнстримном линуксе плачевно, и лично я мейнстримный линукс не использовал никогда, кроме как для проведения сравнительых тестов.

> таковы: Для OpenBSD 4.9 (то есть полгода с момента выхода релиза)

Вашими цифрами можно хвастаться в неформальном разговоре среди фанатов ОС. А в чём и на сколько hardened-линукс уступает/превосходит OpenBSD, из них никак не следует.

> errata ПУСТАЯ. Ну, не нашлось ничего, что тянуло хотя бы на
> проблему надёжности вообще.

И какие вы делаете выводы? Озвучьте их, пожалуйста. И сразу, я уверен, станет ясно, какое отношение они имеют (и имеют ли) к обсуждаемым вовросам.

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

Я с этим и не спорил изначально. Однако принцип разделения привилегий не может быть реализован в отрыве от обеспечения безопасности ядра. Одно другому не противоречит.

> Может, причём. А, может, и нет. Если для злоумышленника нет доступной уязвимости

Если злоумышленник не нашёл в ядре хотя бы одну ошибку, которая поддаётся эксплуатации при условном отсутствии защит ядра, это либо недостаточно продвинутые злоумышленник, либо информация не имеет достаточной ценности. Ядро слишком сложный и насыщенный старым кодом процесс, чтобы исходить из рассчёта на лучшее.

> в ядре, ему хватит и просто рутовых прав. Поэтому источник проблем
> в виде процесса с рутовыми правами надо ТОЖЕ прикрывать.

Конечно, надо. Вопрос в том, когда и насколько это имеет смысл, а когда - нет или не особенно.

> Дважды за десять с лишним лет, да. (см. выше)

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

> Тем не менее, реализовали вовремя. "Если бы да кабы, да росли во
> рту грибы..." Вы пишете так, как будто жалеете, что разработчики OpenBSD

Во-первых, вы скачите от темы к теме. Я вам указал на то, что в OpenSSH было опубликовано меньше уязвимостей чем в ядре, хотя OpenSSH гораздо популярнее и привлекательнее ядра OpenBSD. Это ставит под сомнение вашу гипотезу о том, будто ядро является более сильным звеном, и его нужно защищать во вторую очередь.

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

> это сделали, и что не схлопотали ещё одну 0-day уязвимость.

Одну не схлопотали, так другую схлопотали. А уязвимость, аналогичную первой в IPv6, схлопочат и сейчас, если таковая будет опубликована.

>> Где же ваше соотношение 20/30?
> Навскидку из сделанного в ядре с того момента - улучшили рандомизацию адресного
> пространства, ужесточили контроль над памятью при вводе-выводе, добавили и, разумеется,
> начали использовать опции GCC (-Wstack-larger-than-N, -Wbounded, -Wvariable-decl; описаны
> в gcc-local(1): http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&sekti...
> )...

Опять-таки, мы обсуждаем сравнительную защищённость ядра и сервисов. И не просто, а таковую на момент выхода презентации и её комментариев от PaX Team. Я фактически опроверг ваши аргументы, использовав метрику (количество опубликованных уязвимостей), на которую вы неоднократно ссылались сами. Есть вам, что возразить по существу?

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

Вот моя цитата ^^. А вот ваш ответ:

> Правильно, и поэтому код OpenSSH исследует больше людей, чем код ядра OpenBSD.
> Да и по объёму кода они отличаются в более чем сорок
> раз: 2,5 мегабайта против 106. Вот вам и цифры. А если
> учесть ещё и тот факт, что с возрастанием количества кода, количество
> потенциально уязвимых мест возрастает отнюдь не линейно...

Где в вашем ответе что-либо, опровергающее фактическую корректность или практическую значимость мною сказанного? Вы даже укрепили мои аргументы, указав на следующее:
- OpenSSH подвержен большему вниманию извне
- в ядре гораздо больше кода, чем в OpenSSH
- при возрастании объёмов кода количество потенциальных уязвимостей возрастает нелинено

Теперь вопрос. Считаете ли вы, что эти факты и эмпирические наблюдения опровергают мою точку зрения, а не подкрепляют её?

Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

143. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от paxuser (ok) on 02-Окт-11, 16:36 
>> Потому что одно не отменяет другого. Если у вас (хакера) есть два
>> врага, Вася (ядро) и Петя (обычный процесс), и на Пете есть
>> бронежилет, которого нет на Васе, это ещё не 100% гарантия, что
>> Вася сдастся раньше Пети. Здесь можно вести речь лишь о вероятностях.
> Ну, как показала практика, Петя таки сдался раньше Васи. В OpenSSH опубликовали

Имена перепутал. Вася, который ядро, сдался раньше.

Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

102. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 28-Сен-11, 03:21 
Придумал, как наглядно пояснить проблему с разделением привилегий.

Внимательно читаем пункты 3a и 3b: http://www.openbsd.org/papers/ven05-deraadt/mgp00034.html

3a "Большой процесс делает chroot и сбрасывает привилегии"
3b "Маленький процесс сохраняет привилегии за собой"

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

Смотрим дальше, слайды 35 и 36:
http://www.openbsd.org/papers/ven05-deraadt/mgp00035.html
http://www.openbsd.org/papers/ven05-deraadt/mgp00036.html

Что мы видим в этих схемах? Большие непривилегированные процессы выполняют наибольшее количество функций и взаимодействуют с мелкими привилегированными по очень простому и ограниченному интерфейсу. И всё, вроде бы, замечательно...

Внимание, вопрос! Если бы на схемах каждый из обозначенных там процессов, включая большие непривилегированные, взаимодействовал с большим привилегированным процессом через многофункциональный сложный интерфейс, явилось бы это нарушением выше озвученных принципов разделения привилегий?

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

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

Выводы делайте сами. Могу только съязвить, что гладко было на бумаге, да забыли про овраги. ;)

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

104. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 28-Сен-11, 03:25 
> - не защищено механизмами защиты аналогично пользовательским процессам

Понятнее будет сказать, не защищено механизмами защиты в отличие от пользовательских процессов.

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

106. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 03:59 
> Придумал, как наглядно пояснить проблему с разделением привилегий.
> Внимательно читаем пункты 3a и 3b: http://www.openbsd.org/papers/ven05-deraadt/mgp00034.html
> 3a "Большой процесс делает chroot и сбрасывает привилегии"
> 3b "Маленький процесс сохраняет привилегии за собой"
> Смысл сего действа в уменьшении количества кода, который выполняется в рамках привилегированного
> процесса - чем меньше код, тем меньше в нём уязвимостей (вплоть
> до полного их отсутствия в идеальном случае). Разумеется, внешний интерфейс к
> такому коду тоже должен быть максимально простым и ограниченным.

<...>

>[оверквотинг удален]
> бумаге, а в действительности. Этот процесс - ядро OpenBSD. То самое,
> ядро, которое:
> - имеет абсолютные привилегии в системе
> - не защищено механизмами защиты аналогично пользовательским процессам
> - содержит больше кода, чем любой из пользовательских процессов
> - содержит уязвимости и уже подвергалось эксплуатации через них
> - не было написано разработчиками OpenBSD с нуля
> - не содержит способов уменьшить сложность интерфейса с пользовательскими процессами
> Выводы делайте сами. Могу только съязвить, что гладко было на бумаге, да
> забыли про овраги. ;)

Вы зациклились на одном направлении: защита ядра. Да, это важно. Да, это нужно. Кто-то спорит? - нет. Вы спорите со мной, как будто ваш покорный слуга (или де Раддт, или ещё кто) утверждает, что выделение привилегированного процесса - это мера защиты ядра (хотя в какой-то степени это и так, поскольку уязвимый процесс как раз непривилегированный, то есть его _прямые_ возможности по отношению к ядру такие же, как и в случае сброса привилегий; но не суть). Видимо, это же в голову себе взял г-н Альбертс. Откуда он это взял, если это так, - лично мне непонятно. Может, и не взял - как я уже говорил выше, строить догадки о чужой голове не хочу.

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

111. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от коксюзер on 28-Сен-11, 05:24 
> защита ядра
> защиты ядра
> по отношению к ядру

facepalm.jpg

Да, уважаемый, всё дело в защите ядра. И я, и PaX Team, просто зациклились на ней и потеряли адекватность. На эффективность разделения привилегий на ваших системах факт нашего помешательства не влияет. Вы меня убедили. Срочно иду принимать успокоительные и звонить-записываться на приём к психотерапевту. Спасибо, что раскрыли глаза!

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

91. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  –1 +/
Сообщение от Аноним (??) on 27-Сен-11, 15:35 
> Это чистой воды прагматизм.

Это чистой воды извращение и смешивание ужей и ежей. А давайте оно будет еще и списками процессов рулить? Ну раз запускает их - пусть и управляет заодно. А всякие top и ps вообще убить нафиг как duplicate функционал.

> Или благородный дон предлагает переписывать ВЕСЬ взаимодействующий
> с сетью софт, который только может запускаться в системе? Вы этот
> момент упорно не замечаете.

Написать прогу-враппер, наконец. Типа sudo, но для этой фичи. Route в качестве такового - дикий изврат.

> Она управляет роутингом - в отдельно взятой программе.

Этак можно дойти до управления сокетами, тредами и чем там еще через утилиту route(чтобы совсем уж очевидно). Проблема только в том что это будет изврат. Не, конечно можно вообще все в 1 утиль засунуть - получиться busybox. Только вот смысл существования busybox еще более-менее понятен (ради компактности любой ценой можно и извратиться). А вот смысл извращения с превращением роута в стартер программ - не очень понятен.

> Это освещено в документации. Которой OpenBSD небезосновательно гордится.

Хм... в результате разбудили коксюзера. Ну хоть интересного чтива с техническими подробностями от более-менее разбирающегося в вопросе в коментах добавилось, так что посчитаем что "наброс удачен" :)

[...]
>> роутинговые таблицы. А чем он хуже то? Если route'у можно запускать
>> программы, тогда sudo'у не зазорно в таблицу роутинга слазить.
> Если начинать с того, что для чего было создано, так и Linux был just for fun.

Если я могу понять в чем fun сделать cвой *nix-like когда еще нет оного, то вот осознать в чем fun в превращении роута в запускач мне не понятно. Нет, я понимаю что товарищи поставили костыль новому сисколу как умели. Но по-моему это довольно криво и неочевидно - напрашивается отдельная утилитка-враппер для тех кто не умеет так сам. Ну блин, та же утилита chroot например - враппер к сисколу chroot(). Как раз для тех кто его сам не умеет. Давайте утилитку chroot засунем в route? Ну или в ls. Чтоб враг ни за что не догадался что оказывается есть такой врапепр к сисколу.

> Опять-таки, конструктивных предложений с вашей стороны не видно (мои слова об этом
> вы скромно порезали из цитаты). Троллите плохо. Счастливо оставаться.

А по-моему годно вышло - коксюзера разбудили, коменты стали поинтереснее, с техническими подробностями. ИМХО стало менее уныло читать коменты :)

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

5. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от Аноним (??) on 24-Сен-11, 13:06 
Как у них там идет работа над "многопроцессорностью", ато много нареканий по этому поводу к openbsd.

Лично мне это нужно из за IP carp. Чтобы можно было 2 веб сервера поставить на одном ip. Но каждый из вебсерверов (24 ядра) должен обслуживать большой пресс конектов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Сен-11, 13:35 
> Как у них там идет работа над "многопроцессорностью", ато много нареканий по
> этому поводу к openbsd.
> Лично мне это нужно из за IP carp. Чтобы можно было 2
> веб сервера поставить на одном ip. Но каждый из вебсерверов (24
> ядра) должен обслуживать большой пресс конектов.

Зависит от архитектуры конечных программ. Если они как тот же nginx используют процессы (а не потоки выполнения AKA треды) для разделения работы, или же используют потоки выполнения, но адекватно работают под librthread, то проблем, скорее всего, быть не должно: на web-сервере нагрузка создаётся обычно в основном юзерспейсом (хотя usecase'ы, конечно, бывают разные, о вашем мне не ведомо :) ). В противном случае OpenBSD пока что не подойдёт. (хотя вообще обычно железо подбирается под софт, так что если сервера покупались изначально под какой-то набор ОС и программ, то, скорее всего, любой другой набор будет проигрывать по определению ;) )

Коммиты, уменьшающие зависимость различных частей ядра ОС от работы на одном ядре процессора, периодически всплывают, но о том, чтобы в ближайшем времени разнести ядро по разным ядрам процессора, AFAIK, речь пока не идёт. Хотя кто-то из разработчиков и говорил, что в планах есть даже поддержка NUMA, но о конкретных сроках речи нет.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

15. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 24-Сен-11, 15:49 
Как будет в случае с erlang?
Я так понимаю его, так называемые, легковесные процессы для
операционки выглядят нитями.

И в портах только erlang R13, что то не активно двигается

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

16. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от коксюзер on 24-Сен-11, 16:14 
> Как будет в случае с erlang?
> Я так понимаю его, так называемые, легковесные процессы для
> операционки выглядят нитями.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Michael Shigorin email(ok) on 24-Сен-11, 16:31 
>> Как будет в случае с erlang?
> Нет, его процессы реализованы на уровне ВМ. Но рантайм эрланга использует нити
> для ввода-вывода и поддержки SMP, поэтому проблемы с нитями могут быть.

Эээ... а можно с офтопиком, который и про *nix, и про эрланг? ;-)

Через неделю будет http://conference.osdn.org.ua/ru (Киев) с докладами в т.ч. по эрлангу, а второго октября будет вводный курс по нему же от Erlang Solutions.  Милости просим :)

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

11. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от dimqua (ok) on 24-Сен-11, 14:34 
Свой Apache опенбсдешники теперь забросят?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от anonymous (??) on 24-Сен-11, 15:04 
Да давно пора - 1.3 протух ужасно.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

17. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Сен-11, 16:23 
> Свой Apache опенбсдешники теперь забросят?

Только после того как nginx полностью войдёт в строй. Скорее всего (но это лишь мои догадки), в ближайшем релизе будут присутствовать оба web-сервера, для облегчения миграции.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Augurov email on 24-Сен-11, 15:26 
Ребяты ... Свершилось !!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от mitiok (ok) on 24-Сен-11, 15:43 
ждём когда nginx начнут встраивать в soho роутеры за 35 баксов.
успехов сысоеву!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от Аноним (??) on 24-Сен-11, 20:07 
> ждём когда nginx начнут встраивать в soho роутеры за 35 баксов.

Да он там в общем то спокойно работает. Но есть httpd полегче, которыми и пользуются в данный момент. Там счет памяти на считанные мегабайты идет - за 35 баксов могут максимум 32 мега запаять. Спасибо если не 16.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

22. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от фклфт (ok) on 25-Сен-11, 05:52 
Ну не понимаю я
Зачем в стандартную поставку опенка нужен веб сервер
это примерно такой же маразм что во FreeBSD идет named
ну кому надо тот и пусть доставит !!!
нафига мне на супер роутере еще апач или другой веб сервис нужен, это у линупсятников уже научились в минимальную установку всякую фигню пихать
Возьмите на примере установите по минимуму FreeBSD и любой линух, и просто загляните в top, надеюсь поняли о чем я
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от mma on 25-Сен-11, 09:11 
>зачем в стандартную поставку опенка нужен веб сервер

Тебя никто запускать его не заставляет, более того по дефолту оно не запущено

>это примерно такой же маразм что во FreeBSD идет named

Ты не поверишь, в obsd тоже

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

26. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от nanonymous on 25-Сен-11, 13:49 
>>это примерно такой же маразм что во FreeBSD идет named
> Ты не поверишь, в obsd тоже

Ага. А еще nsd.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

29. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Сен-11, 18:18 
>>>это примерно такой же маразм что во FreeBSD идет named
>> Ты не поверишь, в obsd тоже
> Ага. А еще nsd.

BIND в базовой системе будет жить, пока nsd и unbound не приведут к "виду, удобному для логарифмирования" (unbound сейчас живёт в портах, но намерения по переносу в базу были озвучены). BIND 10 вместе с его Питоном в систему тащить никто не хочет.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

25. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от nanonymous on 25-Сен-11, 13:48 
+1.
Не понимаю, зачем в базе такие вещи держать, есть же порты/пакеты, которые прекрасно работают.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

28. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Сен-11, 18:13 
> +1.
> Не понимаю, зачем в базе такие вещи держать, есть же порты/пакеты, которые
> прекрасно работают.

Дискляймер для потенциальных троллей: ниже следует объяснение (ответ на заданный вопрос), а не скрытая агитация.

Во-первых, софт, имеющийся в базовой системе, более жёстко контролируется и гарантировано работает на всех платформах. В то время как софт в портах гарантированно проверяется лишь на собираемость (по умолчанию в OpenBSD сначала создаётся пакет, а уже потом он устанавливается в систему, в отличие от большинства других ОС, поэтому проверка качественная), а вот запускаемость лишь по возможности: проводить полное тестирование на всех архитектурах весьма сложная задача. Подобное тестирование, AFAIK, производят разве что Debian и RHEL, и то косяки случаются. Так же для порта может быть приемлемо быть временно сломанным на какой-то архитектуре (с наличием соответствующей пометки, разумеется), в то время как базовая система собирается и работоспособна всегда. А Web-сервер в наше время зачастую одна из самых чувствительных частей системы.

Во-вторых, developers just want it. :)

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

31. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от фклфт (ok) on 25-Сен-11, 18:41 
>> +1.
>> Не понимаю, зачем в базе такие вещи держать, есть же порты/пакеты, которые
>> прекрасно работают.
> Во-первых, софт, имеющийся в базовой системе, более жёстко контролируется и гарантировано
> Во-вторых, developers just want it. :)
> В-третьих,

Да просто вообще не вижу смысла в минимальную установку впендюривать какой либо софт
Допустим мне надо просто обыкновенный роутер (коих дофига и почти все на FreeBSD, есть на опенке немного) то на кой вообще на этом роутере будет валятся веб сервис там апач какой нибудь, просто маразм какой то получается, ну пусть этот named апач и так далее уже выносят в расширенную установку
Это после минимальной установки системы FreeBSD/OpenBSD мне приходится еще сидеть выпиливать посторонние сервисы
Даже если присутствует незапущенный сервис на сервере это уже потенциальная угроза
Такая помойка с ненужными библиотеками и приложениями в основном только в линухах при самой минимальной установке а в последнее время смотрю и фряшники начали хвалиться что в минимальной поставке идет еще всякая фигня которую потом надо сидеть еще выпиливать

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

32. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от фклфт (ok) on 25-Сен-11, 18:43 
сендмыло вообще уже достало в минимальной поставке (это я про FreeBSD)


Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Сен-11, 19:12 
> сендмыло вообще уже достало в минимальной поставке (это я про FreeBSD)

Какой-то почтовый сервер нужен в любом случае. Если вы не знаете, зачем, то прямо и не знаю, чем тут можно помочь. Эдак можно в базовую поставку вообще только загрузчик, ядро и init ставить.

На всех не угодить. FreeBSD и OpenBSD позволяют без особых проблем отключить ненужное при сборке, коли уж умолчания вас не устраивают. А персонально под вас, простите, ни *BSD, ни кто ещё систему перекраивать не будет. :)

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

39. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  –1 +/
Сообщение от фклфт (ok) on 26-Сен-11, 06:26 
>Какой-то почтовый сервер нужен в любом случае.

На роутере/шлюзе он нафиг не нужен

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

42. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 12:44 
>>Какой-то почтовый сервер нужен в любом случае.
> На роутере/шлюзе он нафиг не нужен

Обойтись без него можно, да. Как и без браузера для того, чтобы читать Опеннет. Останавливать вас не собираюсь, естественный отбор нас рассудит. :)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

33. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Сен-11, 18:55 
>>> +1.
>>> Не понимаю, зачем в базе такие вещи держать, есть же порты/пакеты, которые
>>> прекрасно работают.
>> Во-первых, софт, имеющийся в базовой системе, более жёстко контролируется и гарантировано
>> Во-вторых, developers just want it. :)
>> В-третьих,
> Да просто вообще не вижу смысла в минимальную установку впендюривать какой либо
> софт

Ну не видите, и хорошо. Кто-то другой видит, и пользуется подходящей ему системой.

> Допустим мне надо просто обыкновенный роутер (коих дофига и почти все на
> FreeBSD, есть на опенке немного) то на кой вообще на этом
> роутере будет валятся веб сервис там апач какой нибудь, просто маразм
> какой то получается,

Зачем на роутере? Да хоть для морды того же nagios, в SOHO-сегменте его обычно ставить просто более некуда. Или там отчёты по трафику смотреть, тоже как бы удобнее напрямую через браузер.

> ну пусть этот named апач и так далее
> уже выносят в расширенную установку
> Это после минимальной установки системы FreeBSD/OpenBSD мне приходится еще сидеть выпиливать
> посторонние сервисы
> Даже если присутствует незапущенный сервис на сервере это уже потенциальная угроза

Чему?! Если он не SUID, то не опаснее утилиты rm. Которая, прошу заметить, обычным пользователям доступна.

> Такая помойка с ненужными библиотеками и приложениями в основном только в линухах

Я в Linux встречался скорее с обратным. То при проблемах с сетью обнаруживаешь отсутствие tcpdump, то sudo нет, то ещё что посмешнее.

> при самой минимальной установке а в последнее время смотрю и фряшники
> начали хвалиться что в минимальной поставке идет еще всякая фигня которую
> потом надо сидеть еще выпиливать

Пожалуйста, не забывайте писать "IMHO". ;)

А в случае с OpenBSD, достаточно положить в каталог с установочными файлами install.site (это прекрасно документировано, между прочим), который будет делать rm -Rf /var/www и что там вам ещё жить мешает. И больше ничего ручками выдирать не надо. Почему это не сделано по умолчанию? Потому что в OpenBSD другая философия для вещей по умолчанию. Но возможности делать по-своему (без заметных дополнительных усилий) никто вас не лишает. :)

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

41. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Василий (??) on 26-Сен-11, 10:30 
> Такая помойка с ненужными библиотеками и приложениями в основном только в линухах
> при самой минимальной установке а в последнее время смотрю и фряшники
> начали хвалиться что в минимальной поставке идет еще всякая фигня которую
> потом надо сидеть еще выпиливать

Прости, троллюшко, но я тебе не верю. Даже в Debian, не самом минималистичном дистрибутиве, пока не скажешь во время установки "хочу DNS-сервер, хочу Web-сервер", ничего этого не будет. И в top особо лишнего тоже ничего нет.

Незапущенный сервис - не угроза, пока его кто-то не запустит. А если этот кто-то может его запустить, то...

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

52. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 26-Сен-11, 18:01 
> по умолчанию в OpenBSD сначала создаётся
> пакет, а уже потом он устанавливается в систему, в отличие от
> большинства других ОС,

Нет. В большинстве систем именно так и происходит.
Сначала собирается бинарь -- потом он ставится.
OpenBSD здесь хвастаться нечем.

> поэтому проверка качественная

Проверка чего?

> , а вот запускаемость лишь по
> возможности: проводить полное тестирование на всех архитектурах весьма сложная задача.
> Подобное тестирование, AFAIK, производят разве что Debian и RHEL, и то
> косяки случаются.

RHEL -- да, Debian -- нет, как и во всех остальных community-based
Linux/BSD/Solaris системах.

> Так же для порта может быть приемлемо быть временно
> сломанным на какой-то архитектуре (с наличием соответствующей пометки, разумеется), в
> то время как базовая система собирается и работоспособна всегда. А Web-сервер
> в наше время зачастую одна из самых чувствительных частей системы.

Не надо путать место, где софт разрабатывается, и место,
куда этот софт потом попадает. Никто не мешает вести разработку на cvs://openbsd.org/,
но пакетировать его в openbsd ports, а не в базовую систему.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

62. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 20:26 
>> по умолчанию в OpenBSD сначала создаётся
>> пакет, а уже потом он устанавливается в систему, в отличие от
>> большинства других ОС,
> Нет. В большинстве систем именно так и происходит.
> Сначала собирается бинарь -- потом он ставится.
> OpenBSD здесь хвастаться нечем.

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

>> поэтому проверка качественная
> Проверка чего?

Сборки и конечной работоспособности.

>> , а вот запускаемость лишь по
>> возможности: проводить полное тестирование на всех архитектурах весьма сложная задача.
>> Подобное тестирование, AFAIK, производят разве что Debian и RHEL, и то
>> косяки случаются.
> RHEL -- да, Debian -- нет, как и во всех остальных community-based

Спасибо за уточнение.

> Linux/BSD/Solaris системах.
>> Так же для порта может быть приемлемо быть временно
>> сломанным на какой-то архитектуре (с наличием соответствующей пометки, разумеется), в
>> то время как базовая система собирается и работоспособна всегда. А Web-сервер
>> в наше время зачастую одна из самых чувствительных частей системы.
> Не надо путать место, где софт разрабатывается, и место,
> куда этот софт потом попадает. Никто не мешает вести разработку на cvs://openbsd.org/,
> но пакетировать его в openbsd ports, а не в базовую систему.

Не мешает (ну, почти, но эти нюансы в принципе решаемы). Только зачем? Если кому-то не нужен Web-сервер, он им не будет пользоваться, и всё. Вот честно, лично я не понимаю, чем он мешает. Если припрёт экономить каждый мегабайт свободного места, то под нож всё равно много чего пойдёт, и зацикливаться на одном Web-сервере как-то глупо. Для особо принципиальных, повторюсь, есть install.site.

Не понимаю, правда, чего копья ломать-то тут? :) Понимаю, если бы не было чего-то нужного. А так флейм на пустом месте.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

86. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 27-Сен-11, 12:23 
>> Сначала собирается бинарь -- потом он ставится.
>> OpenBSD здесь хвастаться нечем.
> Вы не поняли (возможно, я некорректно выразился). Во многих системах пакет собирается
> из того, что устанавливается перед этим в живую систему. В OpenBSD
> фактическая установка происходит в отдельный рабочий каталог, из содержимого которого
> и собирается бинарный пакет.

Все я прекрасно понял.
В NetBSD pkgsrc, например, пакет инсталлируется во временный каталог,
называемый destdir, и потом пакет создается из файлов в этом каталоге.
http://www.netbsd.org/docs/pkgsrc/fixes.html#destdir-support
У нас USE_DESTDIR=yes по умолчанию.
Кроме того, подавляющее число пакетов не требуют для сборки root-а (или fakeroot(1)-а)
(см. PKG_DESTDIR_SUPPORT=user-destdir).

В большинстве же вменяемых дистров Линупса пакеты
собираются с использованием fakeroot(1), и о порче /usr речь тоже не идет.

Ставит пакеты в /usr/local, наверное, только FreeBSD, но даже в этом я не уверен,
посколько ей не интересуюсь.

В DragonFlyBSD,MirBSD,Minix3 - всё тот же pkgsrc.

Ну так о каком "большинстве" идет речь?

> А так флейм на пустом месте.

Это не флейм, это замечание. Для многих неочевидна даже возможность
вести разработку в рамках Net/Open/FreeBSD без
размещения результатов в базовых системах.
Хотя многие вещи имело бы смысл оттуда вынести.
Что конкретно и нужно ли -- отдельный вопрос,
но о такой возможности нужно хотя бы помнить.

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

88. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 27-Сен-11, 13:32 
>>> Сначала собирается бинарь -- потом он ставится.
>>> OpenBSD здесь хвастаться нечем.
>> Вы не поняли (возможно, я некорректно выразился). Во многих системах пакет собирается
>> из того, что устанавливается перед этим в живую систему. В OpenBSD
>> фактическая установка происходит в отдельный рабочий каталог, из содержимого которого
>> и собирается бинарный пакет.
> Все я прекрасно понял.
> В NetBSD pkgsrc, например, пакет инсталлируется во временный каталог,
> называемый destdir, и потом пакет создается из файлов в этом каталоге.
> http://www.netbsd.org/docs/pkgsrc/fixes.html#destdir-support

В OpenBSD аналогично.

> У нас USE_DESTDIR=yes по умолчанию.

В OpenBSD это не отключается by design. :) Ибо нефиг. А зачем оно вам нужно No?

> Кроме того, подавляющее число пакетов не требуют для сборки root-а (или fakeroot(1)-а)
> (см. PKG_DESTDIR_SUPPORT=user-destdir).

Рад за вас.

> В большинстве же вменяемых дистров Линупса пакеты
> собираются с использованием fakeroot(1), и о порче /usr речь тоже не идет.

Угу, только в porting guide это почему-то фиг найдёшь. Может, не там искал, конечно. Но если fakeroot пошёл в массы, то и хорошо.

> Ставит пакеты в /usr/local, наверное, только FreeBSD, но даже в этом я
> не уверен,
> посколько ей не интересуюсь.

Ставит.

> В DragonFlyBSD,MirBSD,Minix3 - всё тот же pkgsrc.
> Ну так о каком "большинстве" идет речь?

Видимо, действительно погорячился. Что ж, оно и к лучшему. :)

>> А так флейм на пустом месте.
> Это не флейм, это замечание. Для многих неочевидна даже возможность
> вести разработку в рамках Net/Open/FreeBSD без
> размещения результатов в базовых системах.
> Хотя многие вещи имело бы смысл оттуда вынести.
> Что конкретно и нужно ли -- отдельный вопрос,
> но о такой возможности нужно хотя бы помнить.

Гм. Разработку можно вести вообще где угодно. :) В OpenBSD есть вполне однозначное описанное мною выше разделение, на которое пользователь может закладываться. Базовая система по определению НЕ ЗАВИСИТ от портов. Некоторое исключение - GNU crap, на котором надо вызывать autoreconf после импорта обновлённой версии, а autotools живут в портах; однако в процессе собственно сборки базовой системы autotools не участвуют.

Базовая система лучше тестируется - просто потому, что софт собирается в её составе. Недавно, например, npppd чуть не вылетел из базовой системы из-за недосмотра мэйнтейнера - сборка сломалась из-за страницы руководства. Кому-то, может, это и смешно - но это свидетельствует о жёстких требованиях к качеству в проекте. Если софт вынести в порты - собственно разработкой-то можно заниматься. Но суммарное качество, которое определяется далеко не только количеством фич, ;) автоматически понизится.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

90. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 27-Сен-11, 14:23 
>> У нас USE_DESTDIR=yes по умолчанию.
> В OpenBSD это не отключается by design. :) Ибо нефиг. А зачем
> оно вам нужно No?

Лично мне не нужно, я выставлял USE_DESTDIR в YES задолго до того,
как он стал таковым по умолчанию.

>> В большинстве же вменяемых дистров Линупса пакеты
>> собираются с использованием fakeroot(1), и о порче /usr речь тоже не идет.
> Угу, только в porting guide это почему-то фиг найдёшь. Может, не там
> искал, конечно. Но если fakeroot пошёл в массы, то и хорошо.

В pkgsrc.txt DESTDIR описан ровно с тех пор, как он появился.
Что такое porting guide и чей он я не знаю. Что касается Линупса, то да,
кое-где там fakeroot прижился. Где-то здесь бегает Шигорин, спроси у него,
как они используют fakeroot. В дебаяне тоже принято собирать пакеты
через fakeroot. В pkgsrc fakeroot, как правило,
не используют, поскольку у нас есть UNPRIVILEGED=yes и fakeroot
для него ничего не дает. Потому пошли более сложным и длинным путем -- через
destdir.

>> Ставит пакеты в /usr/local, наверное, только FreeBSD, но даже в этом я
>> не уверен, посколько ей не интересуюсь.
> Ставит.

Мир праху ее портам, значит.

>> В DragonFlyBSD,MirBSD,Minix3 - всё тот же pkgsrc.
>> Ну так о каком "большинстве" идет речь?
> Видимо, действительно погорячился. Что ж, оно и к лучшему. :)

Мир меняется ;-)

> Если софт вынести в порты - собственно разработкой-то
> можно заниматься. Но суммарное качество, которое определяется
> далеко не только количеством
> фич, ;) автоматически понизится.

Нет. Если ваши порты - это свалка говна, даже если апстрим OpenBSD разработчик,
мне остается только принести соболезнование.

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

96. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  –2 +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-11, 20:08 
> Что касается Линупса, то да, кое-где там fakeroot прижился.
> Где-то здесь бегает Шигорин, спроси у него, как они используют fakeroot.

Шо значит "кое-где", шо значит "бегает"?  Ты сперва расскажи, с какими привилегиями у вас сборочный чрут формируется (в альтовском hasher это псевдорут, в отличие от остальных известных реализаций). :)

> мне остается только принести соболезнование.

PS: пользуясь случаем, хочу принести благодарность участвующим за такой шикарный экскурс.  Я и не думал, что в *BSD доныне настолько всё плохо с этой самой сборкой софта...

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

97. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle (ok) on 27-Сен-11, 22:36 
>> Что касается Линупса, то да, кое-где там fakeroot прижился.
>> Где-то здесь бегает Шигорин, спроси у него, как они используют fakeroot.
> Шо значит "кое-где", шо значит "бегает"?  Ты сперва расскажи, с какими
> привилегиями у вас сборочный чрут формируется (в альтовском hasher это псевдорут,
> в отличие от остальных известных реализаций). :)

Конкретно в моих bulk build setups используется обычный или hardened chroot,
предварительно подготовленный,
после входа в который привилегии сбрасываются.

Можно сконфигурировать на использование fakeroot(1).
Как конфиг напишешь, так и будет.

>> мне остается только принести соболезнование.
> PS: пользуясь случаем, хочу принести благодарность участвующим за такой шикарный экскурс.
>  Я и не думал, что в *BSD доныне настолько всё
> плохо с этой самой сборкой софта...

Опять начинается, как всегда щеки надул и ничего не сказал.
Вот ты же ровным счетом НИЧЕГО не знаешь о том, о чем пытаешься говорить!!!

Ежели чего сказать хочешь, так говори,
а если оскорблять, тогда до свидания.

Все, что я хотел сказать про ваш убогонький hasher, я уже сказал.
Вы не сумели за 10 лет сделать даже вменяемых логов, доступных
сообществу. До свидания, Миша :-P

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

99. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-11, 22:56 
> Вот ты же ровным счетом НИЧЕГО не знаешь о том, о чем пытаешься говорить!!!

Ну разве что с высоты твоего всеведения, о Лёша.  А так кое-что всё же приходится.

> Ежели чего сказать хочешь, так говори, а если оскорблять, тогда до свидания.

Да так, мелкий дружеский наезд и спасибо за пополнение тематического архива. :) (а то вдруг ещё забьёте друг друга ногами, позабыв про чопорность перед всякими линуксоводами)

> Все, что я хотел сказать про ваш убогонький hasher, я уже сказал.

Лёш, ну что ты как детсадовец.  Посмотри http://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2004.html и скажи, что есть неубогонького при такой постановке задачи, или что ты считаешь смехотворным в самой постановке.

А то мне вот то ли смеяться, то ли плакать над твоим "заранее заготовленым чрутом".  Ты его хоть перед каждой собираемой софтиной берёшь чистый или так и лупишь всё в одном?  А когда меняется, скажем, базовый CC -- какие действия необходимы и достаточны для получения актуального чистого сборочного окружения?

> Вы не сумели за 10 лет сделать даже вменяемых логов, доступных сообществу.

Интересно, знакомы ли тебе эти: http://lists.altlinux.org/pipermail/sisyphus-incominger/ (и сложно ли сообразить, что dashboard сделать вовсе не так сложно, как транзакционное изменение репозитория)?

А мне лично скорее хватает сводок из http://lists.altlinux.org/pipermail/sisyphus-cybertalk/ плюс "светофора" на http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc

> До свидания, Миша :-P

До встречи ;-)

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

100. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle (ok) on 27-Сен-11, 23:51 
>> Вот ты же ровным счетом НИЧЕГО не знаешь о том, о чем пытаешься говорить!!!
> Ну разве что с высоты твоего всеведения, о Лёша.

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

> А так
> кое-что всё же приходится.

Что-то как-то незаметно.

>> Ежели чего сказать хочешь, так говори, а если оскорблять, тогда до свидания.
> Да так, мелкий дружеский наезд и спасибо за пополнение тематического архива. :)

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

> (а то вдруг ещё забьёте друг друга ногами, позабыв про чопорность
> перед всякими линуксоводами)

Друг с другом мы уж как-нибудь сладим, не волнуйся.
А вот понты свои дешевые или раскрой или убери совсем.

>> Все, что я хотел сказать про ваш убогонький hasher, я уже сказал.
> Лёш, ну что ты как детсадовец.

Ты бы на себя чаще смотрел.

> Посмотри http://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2004.html

Здесь нет для меня ничего нового, извини, но мимо.

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

Перед сборкой КАЖДОГО пакета, чрут абсолютно чист от результатов
компиляции предущего пакета, просто потому, что "систему" повредить невозможно в принципе, а то, что изменимо -- перезаписывается заново. Каким образом это
достигается -- твое домашнее задание. Еще какие-то вопросы?

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

Чего?

>> Вы не сумели за 10 лет сделать даже вменяемых логов, доступных сообществу.
> Интересно, знакомы ли тебе эти: http://lists.altlinux.org/pipermail/sisyphus-incominger/

ЭТО я уже видел.

> плюс "светофора" на http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc

Смешно. И это мы уже обсуждали, и не раз.
Извини, не впечатлает.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

116. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Michael Shigorin email(ok) on 28-Сен-11, 12:28 
> В отличие от тебя, дорогой, я стараюсь не лезть в темы, в которых не тяну.

Лёш, я немного понимаю в системах сборки программного обеспечения.  И как ты мог заметить, развлекался наблюдаемым молча, пока не началось мерянье тем, у кого destdir круче.  Потому как я сейчас сходу не назову сколь-нибудь вменяемого линукса _без_.

> И уж точно не перехожу на оскорления с первого же поста.

Извини, оскорблять не собирался.  Если ты так болезненно воспринял подкол -- с меня лишнее пиво.

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

Порой и от тебя интересные вещи можно узнать, но далеко не все.  Лёш, дело не в пальцах.  Скорее в том, что принимать за достойный технический уровень.

>>> Все, что я хотел сказать про ваш убогонький hasher, я уже сказал.
>> Лёш, ну что ты как детсадовец.
> Ты бы на себя чаще смотрел.

Смотрю.

>> Посмотри http://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2004.html
> Здесь нет для меня ничего нового, извини, но мимо.

Тогда ответь на вопрос, который поскипал.  Или забери своё "убогонький" себе.

>> А то мне вот то ли смеяться, то ли плакать над твоим
>> "заранее заготовленым чрутом".  Ты его хоть перед каждой собираемой софтиной
>> берёшь чистый или так и лупишь всё в одном?
> Перед сборкой КАЖДОГО пакета, чрут абсолютно чист

Во, это хорошо.

>> А когда меняется, скажем, базовый CC -- какие действия необходимы и достаточны
>> для получения актуального чистого сборочного окружения?
> Чего?

Когда компилятор меняется, что приходится выполнить для обновления эталона чрута?

>>> Вы не сумели за 10 лет сделать даже вменяемых логов, доступных сообществу.
>> Интересно, знакомы ли тебе эти:
> ЭТО я уже видел.

То есть логи, доступные сообществу, всё-таки есть.  Без претензии на вменяемость по твоей (неопубликованной вроде бы) шкале, но тут я скорее с тобой соглашусь, чем буду спорить.

>> плюс "светофора" на http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc
> Смешно. И это мы уже обсуждали, и не раз.  Извини, не впечатлает.

Ну извини, модистку не завели.  Хотя, конечно, встречают по одёжке.

PS: последний раз dashboard писал на коленке при приёмке железа на "Ломоносове" -- надо было выразить в обозримом виде оперативную сводку состояния узлов (запросил IP, взял ядро, смонтировал NFS, доступен, брякнул характерную строку в логи).  Тогда было надо, и написано было очень быстро.  А то, что ты показывал и вроде бы с гордостью, мне бесполезно, иначе бы давно уже накрутил "функциональный аналог".  Вот это только не прими как наезд, поскольку всего лишь пояснение.

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

119. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle email(ok) on 28-Сен-11, 12:56 
> развлекался наблюдаемым молча, пока не началось мерянье тем,
> у кого destdir круче.

Ты даже читать не умеешь. О чем с тобой можно вообще говорить?

> Порой и от тебя интересные вещи можно узнать, но далеко не все.
>  Лёш, дело не в пальцах.  Скорее в том, что
> принимать за достойный технический уровень.

Твой технический уровень я уже видел не раз.

> Тогда ответь на вопрос, который поскипал.

Начав разговор с оскорблений ты надеешься на какие-то
разъяснения с моей стороны? Наивный чукотский мальчик.

> Или забери своё "убогонький" себе.

Сначала ты извинишься за свои наезды, с которыми влез в разговор.

Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

108. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 04:33 
>> мне остается только принести соболезнование.
> PS: пользуясь случаем, хочу принести благодарность участвующим за такой шикарный экскурс.
>  Я и не думал, что в *BSD доныне настолько всё
> плохо с этой самой сборкой софта...

Гм. Плохо? По-моему, плохо, например, это когда в порте (.deb, .ebuild etc.) скрипты приходится писать. Когда бинарный пакет содержит в себе не _указания_, а _скрипты_ для установки, которые ещё и человек правит. Плохо, когда во время конфигурирования и/или компиляции пакету дозволяется лезть, скажем, в домашний каталог пользователя и что-то там читать-писать... Или это в основных пакетных системах Linux сейчас тоже исправлено? (без сарказма спрашиваю)

У каждой системы свои особенности, и идеальных нет. Может, прежде чем "радоваться", сначала хоть для "своих" руководство нормальное напишете? А то этот огрызок - http://www.altlinux.org/%D0%9A%D1%80... - именно что "краткое" руководство. Больше похожее на "досчитаешь до десяти и дёрнешь за кольцо": что делать, если парашют не раскрылся, не уточняется.

В порядке ответной шпильки. ;)

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

107. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Сен-11, 04:16 
>>> У нас USE_DESTDIR=yes по умолчанию.
>> В OpenBSD это не отключается by design. :) Ибо нефиг. А зачем
>> оно вам нужно No?
> Лично мне не нужно, я выставлял USE_DESTDIR в YES задолго до того,
> как он стал таковым по умолчанию.

Я имел в виду вообще в pkgsrc оно зачем бывает нужно? Есть проблемные пакеты? Или просто забыли выпилить наследие? Или ещё почему?

>> Если софт вынести в порты - собственно разработкой-то
>> можно заниматься. Но суммарное качество, которое определяется
>> далеко не только количеством
>> фич, ;) автоматически понизится.
> Нет. Если ваши порты - это свалка говна, даже если апстрим OpenBSD
> разработчик,
> мне остается только принести соболезнование.

Ну что вы сразу "свалка". :( Я вам объясняю, что наиболее качественное тестирование по определению получает софт в базовой системе. Если попытаться его перенести в порты, то тестирования будет меньше. Много, но меньше. Понимаете? Порты - это не самоцель, у них (в OpenBSD) есть чёткое предназначение.

Есть альтернативный вариант развития: превращение пакетов базовой системы во что-то, что можно скормить pkg_add. Это уже интереснее, так как эффективно решит проблему тухлых библиотек в /usr/lib. Пока что у Marc Espie других дел хватает, а большого энтузиазма с чьей-либо ещё стороны я пока не видел. Скажем так: не самая жизненно необходимая вещь.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

113. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle (ok) on 28-Сен-11, 09:13 
>>>> У нас USE_DESTDIR=yes по умолчанию.
>>> В OpenBSD это не отключается by design. :) Ибо нефиг. А зачем
>>> оно вам нужно No?
>> Лично мне не нужно, я выставлял USE_DESTDIR в YES задолго до того,
>> как он стал таковым по умолчанию.
> Я имел в виду вообще в pkgsrc оно зачем бывает нужно? Есть
> проблемные пакеты? Или просто забыли выпилить наследие? Или ещё почему?

В pkgsrc переход на destdir шел постепенно, в отличие от OpenBSD ports,
где неправильные пакеты просто выбросили в один момент, чтобы потом
о них забыть или переписыватьс нуля. Так что USE_DESTDIR=no -- это часть
старого функционала, который никто не стал трогать. Кроме того,
есть странные юзвери, которые почему-то не хотят тратить время
на создание бинаря.

> Ну что вы сразу "свалка". :( Я вам объясняю, что наиболее качественное
> тестирование по определению получает софт в базовой системе. Если попытаться его
> перенести в порты, то тестирования будет меньше. Много, но меньше. Понимаете?

Нет. Не вижу для этого ни единой причины.

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

92. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Аноним (??) on 27-Сен-11, 15:37 
> Зачем в стандартную поставку опенка нужен веб сервер

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

98. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от vle (ok) on 27-Сен-11, 22:52 
> Зачем в стандартную поставку опенка нужен веб сервер
> Это такая загадка природы от BSDшников. Которая сильно портит им карму в
> ряде применений. Ну нравится им так - да пожалуйста, дело хозяйское.

А в ряде применений облегчает.
Например, установочный диск NetBSD под любую архитектуру
мы можешь создать одной командой build.sh,
запустив ее на любой UNIX-like системе,
имея в распоряжении только дерево исходников.
То есть, например, работая в Linux/amd64 ты можешь создать
кастомный или дефолтный образ NetBSD-5.1/ppc.
Назови мне хотя бы одну систему, которую можно так же создать.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

45. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Ку on 26-Сен-11, 15:23 
Я таки не понимать. А apache и nginx с каких пор стали взаимозаменяемы? Nginx с его архитектурой слабо годится для тяжелой динамики на php, в отличии от apache.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Сен-11, 15:32 
> Я таки не понимать. А apache и nginx с каких пор стали
> взаимозаменяемы? Nginx с его архитектурой слабо годится для тяжелой динамики на
> php, в отличии от apache.

Тяжёлая динамика на FastCGI бегает приемлемо; оно, конечно, медленнее, чем отдельным модулем, но как раз для тяжёлых скриптов эти потери несущественны. Зато такая архитектура заметно надёжнее, чем встроенный модуль сервера. Я знаю высоконагруженные системы, где PHP бегает (ну или бегал до недавнего времени, давно не интересовался, как дела в той конторе) исключительно как CGI, и как-то ничего. :)

С другой стороны, как уже говорилось выше, у Apache 1.3 апстрим мёртв, поэтому заменять его было надо. Apache 2.x не подходил из-за изменения лицензии, которое произошло в последних версиях Apache 1.3 (фичи и багфиксы из них были портированы в опёнковский Апач).

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

48. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от Ку on 26-Сен-11, 15:40 
Может я опять чего не понимать, но под FastCGI код надо переписывать, что не всегда возможно. К тому же FastCGI для php был вообще нежизнеспособен несколько лет назад.
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

60. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."  +/
Сообщение от cadmi on 26-Сен-11, 19:41 
> Может я опять чего не понимать, но под FastCGI код надо переписывать,
> что не всегда возможно.

Не понимать. Не надо ничего переписывать.

> К тому же FastCGI для php был
> вообще нежизнеспособен несколько лет назад.

С тех пор написали php-fpm ... И даже включили в апстрим (почти полтора года назад, в 5.3.3)
Родной PHP'шный fastcgi действительно только прямиком на помойку отнести.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру