The OpenNET Project / Index page

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



"Обновление сборки Openwall GNU/*/Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от opennews (?), 25-Май-18, 11:43 
Сформировано (http://www.openwall.com/lists/owl-users/2018/05/24/1) обновление iso-образов (https://mirrors.kernel.org/openwall/Owl/3.1-stable/iso/) и шаблонов контейнеров OpenVZ стабильной ветки Openwall GNU/*/Linux (Owl) 3.1-stable (http://www.openwall.com/Owl/ru/). По сравнению с прошлым обновлением iso-образов, выпущенным в августе 2016 года, в состав нового выпуска включены накопившиеся (http://www.openwall.com/Owl/CHANGES-3.1-stable.shtml) обновления с устранением уязвимостей, в том числе исправлены уязвимости в ядре Linux, glibc, openssl, procps-ng, db4,  openssh, bind и  gnupg. Также обновлены шаблоны контейнеров для  OpenVZ и сборки (https://mirrors.edge.kernel.org/openwall/Owl/current/iso/) находящейся в разработке ветки Owl-current, которая последние несколько лет не развивается и находится в состоянии сопровождения (устраняются только критические уязвимости).


Owl представляет собой компактный дистрибутив GNU/Linux, ориентированный на обеспечение высокой безопасности, который  может использоваться как для создания высокозащищённых   серверных систем, так и для создания базовой начинки изолированных контейнеров и организации работы контейнерной виртуализации на основе OpenVZ. В дистрибутиве по умолчанию применяются (http://www.openwall.com/Owl/ru/CONCEPTS.shtml) передовые методы обеспечения защиты, используются наиболее безопасные настройки (например, по умолчанию не поставляется программ с флагом suid) и поставляются только пакеты, заслуживающие доверия и прошедшие аудит исходного кода. Кроме готовых бинарных пакетов, предоставляются удобные средства для пересборки пакетов из исходных текстов (make buildworld (http://www.openwall.com/Owl/ru/BUILD.shtml)) и формирования iso-образа или начинки виртуального окружения.

URL: http://www.openwall.com/lists/owl-users/2018/05/24/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=48656

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

Оглавление

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


1. "Обновление сборки Openwall GNU/*/Linux"  –7 +/
Сообщение от Диносуслик (?), 25-Май-18, 11:43 
Молодцы!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от Аноним (-), 25-Май-18, 18:47 
А что значит этот звездолинукс в названии?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Обновление сборки Openwall GNU/*/Linux"  +1 +/
Сообщение от solardiz (ok), 25-Май-18, 19:32 
Звездочка означает что многие компоненты и не GNU и не Linux, но не менее важны. Если уж rms настаивает на упоминании GNU, то логично хоть как-то упомянуть остальное.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от Аноним (-), 26-Май-18, 23:12 
Сейчас режим сопровождения, а каковы перспективы?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Обновление сборки Openwall GNU/*/Linux"  +2 +/
Сообщение от solardiz (ok), 27-Май-18, 12:10 
Перспективы не ясны. Возможен переход на ядра OpenVZ/Virtuozzo 7 и обновление userland'а, чтобы получить легковесную альтернативу VzLinux (без bloat'а, пришедшего в userland VzLinux из RHEL7, без prl_disp_service). В сочетании с этим возможно мы, наконец, включим в Owl набор пакетов для веб-хостинга (начиная с nginx), чтобы Owl была более применима и внутри контейнеров тоже. Либо же продолжим сопровождение и потом будет EOL. Одна из причин нынешней стагнации в том, что c Owl у нас не связано никакого дохода - когда-то мы предоставляли услуги на базе Owl, но сейчас нам это неинтересно (так как не масштабируется и отвлекает от новых проектов). С другой стороны, легковесная альтернатива VzLinux и веб-сайты (включая wiki и т.п.) нужны и нам самим, сидеть на устаревших системах еще долго не выйдет (нужна поддержка новых версий протоколов и т.д.), а существующие дистрибутивы во многом не устраивают. Заодно на базе Owl можно опробовать будущий yescrypt-lite для последующей его интеграции другими дистрибутивами (аналогично тому как в 2000 году мы сделали с crypt_blowfish). Так что посмотрим.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от Аноним (-), 27-Май-18, 15:09 
Спасибо за развернутый ответ, будем наблюдать, в т.ч. за yescrypt.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от solardiz fan (?), 24-Июн-18, 15:48 
solardiz, ответь пожалуйста:

1) Какой из 3 путей обеспечения максимальной безопасности системы ты считаешь более правильным, через:
- дизайн https://en.wikipedia.org/wiki/Secure_by_design
- изоляцию https://en.wikipedia.org/wiki/Qubes_OS
- неясность https://en.wikipedia.org/wiki/Security_through_obscurity
- сочетание (например дизайн + изоляция, типа Openwall на dom0 в качестве хост-системы для множества Qubes(Xen)-систем)
- свой вариант

2) Какие системы сборки тебе кажутся более правильными и технологичными:
- Openwall-овская (Окружение состоит из двух деревьев каталогов. Одно дерево содержит оригинальные архивы исходных текстов. Другое, размещенное в CVS-репозитарии, содержит правила сборки, исправления, а также специфические для Owl дополнения к пакетам. На основе этих двух деревьев исходных текстов собираются бинарные пакеты. Мы используем RPM для работы с готовыми бинарными пакетами, что обеспечивает системе на базе Owl корректную обработку взаимозависимых пакетов от (или рассчитанных на) Red Hat Linux и другие дистрибутивы.)
- альтовская https://www.altlinux.org/О_стратегии_сборки_RPM_пакетов
- Guix-овская https://arxiv.org/pdf/1305.4584v1.pdf
- свой вариант

3) Не преувеличено ли значение воспроизводимых сборок https://reproducible-builds.org/ ? Насколько важна воспроизводимость для безопасности?

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

13. "Обновление сборки Openwall GNU/*/Linux"  +1 +/
Сообщение от solardiz (ok), 01-Июл-18, 21:06 
0) Не советую быть fan'ом.

1) Сочетание всех или части перечисленных путей, а также simplicity и security through diversity (сюда могут входить такие вещи как ASLR, но также и такие как использование редкой OS). В порядке важности я бы их расставил примерно так: simplicity, design, isolation, diversity, obscurity. Причем obscurity уровня конкретного внедрения, а не уровня продукта.

Насчет design (хорошо продуманные API, качественный код без багов) vs. isolation (privilege separation), вот интересное сравнение от DJB, где он как-бы пришел к выводу что privsep в qmail мало что давал (так как для пользователей qmail важна конфиденциальность и т.д. e-mail, а не только невозможность атакующего получить root), а вот хороший дизайн был важен - https://cr.yp.to/papers.html#qmailsec - но это одно субъективное мнение с точки зрения мейнтейнера, которому отвечать за свой проект. Ему действительно пришлось бы отвечать за любой баг. С точки зрения сисадмина или владельца бизнеса, как бы e-mail ни был важен, на том же оборудовании может быть и что-то еще важное (и даже если оно менее важное, то его компрометация это всё равно дополнительный ущерб), поэтому изоляция тоже важна.

Также, играет роль простота. Если дизайн простой, то там меньше чего и менее важно изолировать. И наоборот, если сложный, то изоляция - это способ научиться любить атомную бомбу (в данном случае - систему настолько сложную, что провести ее аудит и быть сколько-нибудь уверенным в том что ничего важного не упущено, нереально) и, условно говоря, не беспокоиться. На том же QubesOS, если в качестве гостевых систем взяты Fedora, то обезопасить их как-либо кроме как изоляцией не реалистично. Реально же беспокоиться всё равно есть о чем - об атаках внутри VM (например, одно злонамеренное e-mail сообщение приведет к утечке остальных), а также о бекдорах в той же Fedora (где разработчиков очень много, а значит и легко скомпрометировать доступ хотя бы одного из них), которые могут прилететь с обновлением одновременно во все VM (если их наивно обновлять-таки - типа, best practice и всё такое).

Owl на dom0 в Qubes по-моему не имеет смысла. Owl отличается разграничением привилегий внутри системы, а в нынешней модели угроз Qubes это не актуально, особенно на dom0. Owl внутри VM в Qubes имеет чуть больше смысла - если неудобно и слишком затратно на каждую мелкую изолируемую под-задачу использовать отдельную VM, то можно внутри Qubes'овой VM еще иметь несколько разграниченных аккаунтов и/или OpenVZ контейнеров.

1,2) Я не считаю универсально более правильным ни один из вариантов. Всё зависит от задачи и обстоятельств. В Owl, мы вынужденно выбрали RPM, чтобы быть хоть как-то пакетно-совместимыми с тогдашними дистрибутивами. Да и сам выбор Linux'а за основу тоже был сделан несмотря на понимание недостатков. Делали то, что считали займет свою нишу. Не хотели повторять то, что уже неплохо делали другие (*BSD).

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

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

14. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от рпрарпо (?), 21-Июл-18, 05:50 
> 1) Сочетание всех или части перечисленных путей, а также simplicity и security
> through diversity (сюда могут входить такие вещи как ASLR, но также
> и такие как использование редкой OS). В порядке важности я бы
> их расставил примерно так: simplicity, design, isolation, diversity, obscurity. Причем
> obscurity уровня конкретного внедрения, а не уровня продукта.

(Спасибо за развёрнутый ответ) Под такой порядок важности более-менее подходит QubesOS - её Xen-окружения на порядки проще крутящихся внутри них Linux-ов (simplicity + isolation), а вот с design беда - Fedora внутри окружений действительно ненадёжна. Но внутри можно поставить Debian вместо Fedora насколько я помню.

> На том же QubesOS, если в качестве гостевых систем взяты Fedora,
> то обезопасить их как-либо кроме как изоляцией не реалистично. Реально же
> беспокоиться всё равно есть о чем - об атаках внутри VM
> (например, одно злонамеренное e-mail сообщение приведет к утечке остальных) а также
> о бекдорах в той же Fedora (где разработчиков очень много, а
> значит и легко скомпрометировать доступ хотя бы одного из них), которые
> могут прилететь с обновлением одновременно во все VM (если их наивно
> обновлять-таки - типа, best practice и всё такое).

Да, такие же мысли. Именно это и останавливает от использования QubesOS - в этом "ехал Fedora через Fedora" скорее всего возможно сделать такие вставки в Fedora-template которые смогут скомпроментировать корневое окружение Fedora-dom0. Тео из OpenBSD комментируя Qubes указывал что dom0 это их (Кубиков) самая уязвимая часть. Хотя Сноуден пользуется, а ему как человеку бывшему "с той стороны", наверняка видней.

Как думаешь, какая ОС была бы понадёжнее Fedora на dom0? (Мне кажется, для этого по сути диспетчера Xen-контейнеров там необязателен даже полноценный Linux, достаточно какого-нибудь Redox-а https://www.opennet.ru/opennews/art.shtml?num=43105 адаптированного под Xen)

> Owl внутри VM в Qubes имеет чуть
> больше смысла - если неудобно и слишком затратно на каждую мелкую
> изолируемую под-задачу использовать отдельную VM, то можно внутри Qubes'овой VM еще
> иметь несколько разграниченных аккаунтов и/или OpenVZ контейнеров.

Owl-template был бы всяко понадёжнее не только Fedora-template, но и вообще любого template который сейчас в ходу на Qubes (Debian, Arch, Ubuntu). Но для того чтобы его сделать, надо вникать в Qubes, а там та ещё наркомания, со слов одного ЛОРовца, который хотел сделать Gentoo-template, но так и не осилил.

> 1,2) Я не считаю универсально более правильным ни один из вариантов. Всё
> зависит от задачи и обстоятельств. В Owl, мы вынужденно выбрали RPM,
> чтобы быть хоть как-то пакетно-совместимыми с тогдашними дистрибутивами. Да и сам
> выбор Linux'а за основу тоже был сделан несмотря на понимание недостатков.
> Делали то, что считали займет свою нишу. Не хотели повторять то,
> что уже неплохо делали другие (*BSD).

Я понимаю что про сборку правильнее спрашивать системщика а не безопасника, но всё-таки, если есть задача выбора наиболее технологичной и универсальной системы сборки (которая могла бы использоваться и на настольных ЭВМ, и на серверах, и на мобилках) в вакууме, что бы ты выбрал из всего разнобразия систем сборок, который есть на сегодняшний день?

ПМСМ из того что есть наиболее многообещающими выглядят nix/guix но они ещё сыроваты (в тот же guix нельзя взять и просто так установить KDE) и привязаны к своим системам инициализации. В идеале, было бы здорово если бы была универсальная система типа модульного nix/guix, который не был бы жёстко "приколочен гвоздями" к systend/dmd соответственно, и мог бы гибко менять абсолютно любые компоненты системы кроме собственно ядра (что-то вроде gentoo-подобного nix/guix, со всеми их плюшками - декларативностью, откатами, побитовой воспроизводимостью и т.д.).

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

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

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

15. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от solardiz (ok), 21-Июл-18, 12:20 
Qubes dom0 не использует и не обновляется из template. На него обновления скачиваются (через sys-firewall, так как сам dom0 доступа в сеть не имеет) и ставятся отдельно. Или не ставятся, если не хочешь.

На dom0 (да и не только) действительно не обязательно Linux, но если Linux, то я рекомендовал взять за основу Alpine.

Owl на Qubes без проблем ставится в HVM, но применения там Owl (если не добавлять много чего еще) очень ограничены.

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

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

16. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от рпрарпо (?), 21-Июл-18, 18:45 
> Qubes dom0 не использует и не обновляется из template. На него обновления
> скачиваются (через sys-firewall, так как сам dom0 доступа в сеть не
> имеет) и ставятся отдельно. Или не ставятся, если не хочешь.

(Спасибо за быстрый ответ) Надо ставить, в Xen-е же тоже периодически появляются уязвимости (хотя и не так часто как в ядре).

> На dom0 (да и не только) действительно не обязательно Linux, но если
> Linux, то я рекомендовал взять за основу Alpine.

Спасибо за совет мудрый, только сейчас вспомнил, что у Alpine вроде бы даже ядро до сих пор заGrSec-уренное. Легковесный и безопасный - то что докторо прописал для dom0.

> Owl на Qubes без проблем ставится в HVM

Неожиданно и приятно, а как именно ставится? В принципе, задним числом сейчас понимаю, что так и должно быть - Owl же изначально не очень далеко от Fedora находится, и с QubesOS это как раз тот случай, когда RH-совместимость Owl  - однозначный плюс. Хотелось бы попробовать Owl-template в текущих Кубиках 4.0 (заодно будет повод снова их потестить).

>но применения там Owl (если не добавлять много чего еще) очень ограничены.

Обычный просмотр статеек-роликов и зависание на форумах скорее всего потянет, не? Если бы ещё как выше было написано Owl-template мог бы крутить внутри себя OpenVZ, было бы вообще круто.

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

Да понятно что без бутылки^C^C^C отдельного детального исследования тут не разобраться, я про обычную поверхностную оценку в жанре "простой форумный трёп". Интересно же знать мнение спеца. Просто думаю - стоит тратить время на то чтобы вникать в guix/nix и всю эту функциональную хренотень, или просто дальше сидеть на Кальке.

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

17. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от solardiz (ok), 21-Июл-18, 20:21 
Обновления Xen да, желательно ставить. Еще обновления Qubes-специфичных компонентов. Еще, если заморачиваться на Spectre, можно ставить обновления микрокода для его использования ядрами и Xen'ом. Всё остальное на dom0 обычно не особо нужно обновлять, и обновление может не оправдывать риск. Из коробки, делать обновления выборочно неудобно.

У Alpine ядро, как я понимаю, уже без grsecurity, но для Qubes dom0 это совершенно не важно и я говорил скорее об Alpine'овом минималистичном userland'е, а ядро всё равно какое в Qubes больше подойдет.

Owl на Qubes в HVM просто ставится из ISO'шки, как любая другая система. Без template, без какой-либо интеграции. Получается окошко с консолью и опционально доступ по ssh из некоторых других VM (лучше из одной). Похожесть на Fedora тут ни при чем.

"Обычный просмотр статеек-роликов и зависание на форумах" потянет только в текстовой консоли, так как X'ов в Owl из коробки нет. Реальные применения: mutt, ssh оттуда на внешние сервера, сборка/использование чего-то консольного, подпись релизов. Всё это под разными аккаунтами там, без запуска под эти отдельные задачи целых VM'ок. OpenVZ-контейнеры с чем-то достаточно старым чтобы работало под тамошним OpenVZ/RHEL5 ядром (то есть Owl же и еще, например, CentOS 6). Поэтому "применения там Owl (если не добавлять много чего еще) очень ограничены."

Я не спец по системам сборки.

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

18. "Обновление сборки Openwall GNU/*/Linux"  +/
Сообщение от рпрарпо (?), 24-Июл-18, 18:22 
> Обновления Xen да, желательно ставить. Еще обновления Qubes-специфичных компонентов.
> Еще, если заморачиваться на Spectre, можно ставить обновления микрокода для его
> использования ядрами и Xen'ом. Всё остальное на dom0 обычно не особо
> нужно обновлять, и обновление может не оправдывать риск. Из коробки, делать
> обновления выборочно неудобно.

Да, надо понимать, какая часть обновления затрагивает нужное (микрокод), а какая - ненужное.

> У Alpine ядро, как я понимаю, уже без grsecurity, но для Qubes
> dom0 это совершенно не важно и я говорил скорее об Alpine'овом
> минималистичном userland'е, а ядро всё равно какое в Qubes больше подойдет.

А, ты про то что Alpine "худенький". Его кстати с учётом этой "худобы" можно и в template-ах использовать, вместо Fedora/Debian.

> Owl на Qubes в HVM просто ставится из ISO'шки, как любая другая
> система. Без template, без какой-либо интеграции.

До чего прогресс дошёл (а может я когда крайний раз тестил Кубики просто пропустил эту возможность, ставить прям iso-шкой).

>Получается окошко с консолью и
> опционально доступ по ssh из некоторых других VM (лучше из одной).
> Похожесть на Fedora тут ни при чем.

А, понятно. А я думал это как-то связано.

> "Обычный просмотр статеек-роликов и зависание на форумах" потянет только в текстовой консоли,
> так как X'ов в Owl из коробки нет. Реальные применения: mutt,
> ssh оттуда на внешние сервера, сборка/использование чего-то консольного, подпись релизов.
> Всё это под разными аккаунтами там, без запуска под эти отдельные
> задачи целых VM'ок. OpenVZ-контейнеры с чем-то достаточно старым чтобы работало под
> тамошним OpenVZ/RHEL5 ядром (то есть Owl же и еще, например, CentOS
> 6). Поэтому "применения там Owl (если не добавлять много чего еще)
> очень ограничены."

А, понятно, жёсткую консоль я не осилю.

> Я не спец по системам сборки.

В любом случае, спасибо за подробные отеты.

Хотелось бы тебя ещё "помучить" расспросами про то что ты думаешь про https://ru.wikipedia.org/wiki/Subgraph_OS которая как написано на Вики "упоминается Эдвардом Сноуденом как потенциальный потенциал[8]." и про другие перспективные с точки зрения безопасности ОСи, которые ты сейчас котируешь как "безопасник", но возможно это будет уже слишком.

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьПоддержатьВебмастеруГИД  
Hosting by Ihor