> 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.dev/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) Воспроизводимость сборок важна, если ей пользоваться, и не важна если нет.
> Пока ей мало кто пользуется, она мало важна, но направление это
> потенциально важное и наличие воспроизводимости (с планом этой воспроизводимостью либо
> пользоваться самим, либо доверять кому-то третьему) вполне может стать одним из
> критериев при выборе системы.
Понятно, спасибо.