https://opennet.me/openforum/vsluhforumID3/114403.html Сформировано (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, которая последние несколько лет не развивается и находится в состоянии сопровождения (устраняются только критические уязвимости).<br><br><br><br><br>Owl представляет собой компактный дистрибутив GNU/Linux, ориентированный на обеспечение высокой безопасности, который может использо https://opennet.me/openforum/vsluhforumID3/114403.html#18 Tue, 24 Jul 2018 15:22:15 GMT &gt; Обновления Xen да, желательно ставить. Еще обновления Qubes-специфичных компонентов. <br>&gt; Еще, если заморачиваться на Spectre, можно ставить обновления микрокода для его <br>&gt; использования ядрами и Xen'ом. Всё остальное на dom0 обычно не особо <br>&gt; нужно обновлять, и обновление может не оправдывать риск. Из коробки, делать <br>&gt; обновления выборочно неудобно.<br><br>Да, надо понимать, какая часть обновления затрагивает нужное (микрокод), а какая - ненужное.<br><br>&gt; У Alpine ядро, как я понимаю, уже без grsecurity, но для Qubes <br>&gt; dom0 это совершенно не важно и я говорил скорее об Alpine'овом <br>&gt; минималистичном userland'е, а ядро всё равно какое в Qubes больше подойдет. <br><br>А, ты про то что Alpine "худенький". Его кстати с учётом этой "худобы" можно и в template-ах использовать, вместо Fedora/Debian.<br><br>&gt; Owl на Qubes в HVM просто ставится из ISO'шки, как любая другая <br>&gt; система. Без template, без какой-либо интеграции. <br><br>До чего прогресс дошёл (а может я когда крайний раз тестил Кубики просто пропустил эту возможност https://opennet.me/openforum/vsluhforumID3/114403.html#17 Sat, 21 Jul 2018 17:21:41 GMT Обновления Xen да, желательно ставить. Еще обновления Qubes-специфичных компонентов. Еще, если заморачиваться на Spectre, можно ставить обновления микрокода для его использования ядрами и Xen'ом. Всё остальное на dom0 обычно не особо нужно обновлять, и обновление может не оправдывать риск. Из коробки, делать обновления выборочно неудобно.<br><br>У Alpine ядро, как я понимаю, уже без grsecurity, но для Qubes dom0 это совершенно не важно и я говорил скорее об Alpine'овом минималистичном userland'е, а ядро всё равно какое в Qubes больше подойдет.<br><br>Owl на Qubes в HVM просто ставится из ISO'шки, как любая другая система. Без template, без какой-либо интеграции. Получается окошко с консолью и опционально доступ по ssh из некоторых других VM (лучше из одной). Похожесть на Fedora тут ни при чем.<br><br>"Обычный просмотр статеек-роликов и зависание на форумах" потянет только в текстовой консоли, так как X'ов в Owl из коробки нет. Реальные применения: mutt, ssh оттуда на внешние сервера, сборка/использование чего-то консольн https://opennet.me/openforum/vsluhforumID3/114403.html#16 Sat, 21 Jul 2018 15:45:24 GMT &gt; Qubes dom0 не использует и не обновляется из template. На него обновления <br>&gt; скачиваются (через sys-firewall, так как сам dom0 доступа в сеть не <br>&gt; имеет) и ставятся отдельно. Или не ставятся, если не хочешь.<br><br>(Спасибо за быстрый ответ) Надо ставить, в Xen-е же тоже периодически появляются уязвимости (хотя и не так часто как в ядре).<br><br>&gt; На dom0 (да и не только) действительно не обязательно Linux, но если <br>&gt; Linux, то я рекомендовал взять за основу Alpine.<br><br>Спасибо за совет мудрый, только сейчас вспомнил, что у Alpine вроде бы даже ядро до сих пор заGrSec-уренное. Легковесный и безопасный - то что докторо прописал для dom0.<br><br>&gt; Owl на Qubes без проблем ставится в HVM<br><br>Неожиданно и приятно, а как именно ставится? В принципе, задним числом сейчас понимаю, что так и должно быть - Owl же изначально не очень далеко от Fedora находится, и с QubesOS это как раз тот случай, когда RH-совместимость Owl - однозначный плюс. Хотелось бы попробовать Owl-template в текущих Кубиках 4.0 (заодно будет повод снова их https://opennet.me/openforum/vsluhforumID3/114403.html#15 Sat, 21 Jul 2018 09:20:37 GMT Qubes dom0 не использует и не обновляется из template. На него обновления скачиваются (через sys-firewall, так как сам dom0 доступа в сеть не имеет) и ставятся отдельно. Или не ставятся, если не хочешь.<br><br>На dom0 (да и не только) действительно не обязательно Linux, но если Linux, то я рекомендовал взять за основу Alpine.<br><br>Owl на Qubes без проблем ставится в HVM, но применения там Owl (если не добавлять много чего еще) очень ограничены.<br><br>У меня нет задачи "выбора наиболее технологичной и универсальной системы сборки", поэтому нет и готового ответа на этот вопрос. Если бы такая задача всерьез возникла, я бы подумал о ее оправданности (часто специализированные решения лучше универсального) и либо от нее отказался, либо потратил немало времени на изучение имеющихся вариантов.<br> https://opennet.me/openforum/vsluhforumID3/114403.html#14 Sat, 21 Jul 2018 02:50:31 GMT &gt; 1) Сочетание всех или части перечисленных путей, а также simplicity и security <br>&gt; through diversity (сюда могут входить такие вещи как ASLR, но также <br>&gt; и такие как использование редкой OS). В порядке важности я бы <br>&gt; их расставил примерно так: simplicity, design, isolation, diversity, obscurity. Причем <br>&gt; obscurity уровня конкретного внедрения, а не уровня продукта.<br><br>(Спасибо за развёрнутый ответ) Под такой порядок важности более-менее подходит QubesOS - её Xen-окружения на порядки проще крутящихся внутри них Linux-ов (simplicity + isolation), а вот с design беда - Fedora внутри окружений действительно ненадёжна. Но внутри можно поставить Debian вместо Fedora насколько я помню.<br><br>&gt; На том же QubesOS, если в качестве гостевых систем взяты Fedora, <br>&gt; то обезопасить их как-либо кроме как изоляцией не реалистично. Реально же <br>&gt; беспокоиться всё равно есть о чем - об атаках внутри VM <br>&gt; (например, одно злонамеренное e-mail сообщение приведет к утечке остальных) а также <br>&gt; о бекдорах в той же Fedora (г https://opennet.me/openforum/vsluhforumID3/114403.html#13 Sun, 01 Jul 2018 18:06:12 GMT 0) Не советую быть fan'ом.<br><br>1) Сочетание всех или части перечисленных путей, а также simplicity и security through diversity (сюда могут входить такие вещи как ASLR, но также и такие как использование редкой OS). В порядке важности я бы их расставил примерно так: simplicity, design, isolation, diversity, obscurity. Причем obscurity уровня конкретного внедрения, а не уровня продукта.<br><br>Насчет design (хорошо продуманные API, качественный код без багов) vs. isolation (privilege separation), вот интересное сравнение от DJB, где он как-бы пришел к выводу что privsep в qmail мало что давал (так как для пользователей qmail важна конфиденциальность и т.д. e-mail, а не только невозможность атакующего получить root), а вот хороший дизайн был важен - https://cr.yp.to/papers.html#qmailsec - но это одно субъективное мнение с точки зрения мейнтейнера, которому отвечать за свой проект. Ему действительно пришлось бы отвечать за любой баг. С точки зрения сисадмина или владельца бизнеса, как бы e-mail ни был важен, на том ж https://opennet.me/openforum/vsluhforumID3/114403.html#12 Sun, 24 Jun 2018 12:48:21 GMT solardiz, ответь пожалуйста:<br><br>1) Какой из 3 путей обеспечения максимальной безопасности системы ты считаешь более правильным, через:<br>- дизайн https://en.wikipedia.org/wiki/Secure_by_design<br>- изоляцию https://en.wikipedia.org/wiki/Qubes_OS<br>- неясность https://en.wikipedia.org/wiki/Security_through_obscurity<br>- сочетание (например дизайн + изоляция, типа Openwall на dom0 в качестве хост-системы для множества Qubes(Xen)-систем)<br>- свой вариант<br><br>2) Какие системы сборки тебе кажутся более правильными и технологичными:<br>- Openwall-овская (Окружение состоит из двух деревьев каталогов. Одно дерево содержит оригинальные архивы исходных текстов. Другое, размещенное в CVS-репозитарии, содержит правила сборки, исправления, а также специфические для Owl дополнения к пакетам. На основе этих двух деревьев исходных текстов собираются бинарные пакеты. Мы используем RPM для работы с готовыми бинарными пакетами, что обеспечивает системе на базе Owl корректную обработку взаимозависимых пакетов от (или рассчитанных на) Red https://opennet.me/openforum/vsluhforumID3/114403.html#11 Sun, 27 May 2018 12:09:21 GMT Спасибо за развернутый ответ, будем наблюдать, в т.ч. за yescrypt.<br> https://opennet.me/openforum/vsluhforumID3/114403.html#10 Sun, 27 May 2018 09:10:25 GMT Перспективы не ясны. Возможен переход на ядра OpenVZ/Virtuozzo 7 и обновление userland'а, чтобы получить легковесную альтернативу VzLinux (без bloat'а, пришедшего в userland VzLinux из RHEL7, без prl_disp_service). В сочетании с этим возможно мы, наконец, включим в Owl набор пакетов для веб-хостинга (начиная с nginx), чтобы Owl была более применима и внутри контейнеров тоже. Либо же продолжим сопровождение и потом будет EOL. Одна из причин нынешней стагнации в том, что c Owl у нас не связано никакого дохода - когда-то мы предоставляли услуги на базе Owl, но сейчас нам это неинтересно (так как не масштабируется и отвлекает от новых проектов). С другой стороны, легковесная альтернатива VzLinux и веб-сайты (включая wiki и т.п.) нужны и нам самим, сидеть на устаревших системах еще долго не выйдет (нужна поддержка новых версий протоколов и т.д.), а существующие дистрибутивы во многом не устраивают. Заодно на базе Owl можно опробовать будущий yescrypt-lite для последующей его интеграции другими дистрибутивами (анал