Насколько безопасна Embox OS?

Но это касается только ядра, а нужно рассматривать систему в целом!

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

Это не слухи. Речь как раз о том, что система гораздо больше чем только ядро, и если у вас ядро работает, но нет связи по сети (сетевуха упала) то в принципе вам ни холодно не жарко, где упало, ядро перегрузится или будет постоянно перегружаться сетевуха. Кстати скорость загрузки Embox всех впечатляет:)

Проблема не только в out of service, но и потенциально возможном взломе системы.

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

Проблема не только в out of service, но и потенциально возможном взломе системы.

Повторюсь, эту проблему мы решаем статической сборкой, хотите сделайте сеть как сервер, никто не мешает. Но в Embox убраны механизмы которые не требуются для работы системы, следовательно исключен произвольный сценарий. Конечно это разработчик закладывает, если он разрешит…

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

Вы имеете ввиду, что в Embox отсутствует классический user-land с сотнями CLI утилит, и десятками переконфигурируемых сервисов?

Вы имеете ввиду, что в Embox отсутствует классический user-land с сотнями CLI утилит, и десятками переконфигурируемых сервисов?

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

Я же говорю, это не ядро в классическом смысле и даже не ОС, это скорее конструктор для ОС. Идея позаимствована из принципа libOS, но в отличие от классических маленьких ОС РВ, Embox сохраняет свойства больших ОС и может быть настроен как микроядро, если так решит разработчик конечной системы.

Вероятно похожего эффекта в плане ограничений по количеству установленного софта можно достичь при запуске обычной OS с урезанным количеством пакетов с LiveCD (на реальной readonly болванке) с readonly FS?

Особенно после залочек типа:

https://github.com/anthraxx/linux-hardened

https://madaidans-insecurities.github.io/guides/linux-hardening.html

https://wiki.archlinux.org/title/Bubblewrap

https://www.whonix.org/#features

Нет, нельзя. При наличие рутовых прав, вы прекрасно меняете права на файловую систему и запускаете там любой софт. Во всяких закрытых конторах пытались это делать удаляя usb разъемы и опечатывая диски, но это работает только до определенного момента, пока реально не понадобилось что то поставить. Гораздо лучше защита на основе дискретного + мандатного доступа (SELinux), но и там все рушится из за пользователей, поскольку в системе есть все и при получении соотвествующих прав… Собственно это причина по которой всякие ботнеты на камерах и роутерах появляются. И от этого не защищает микроядерность ОС.

При наличие рутовых прав,

А как их получить?

С помощью эксплойта дров? В микроядерной оси?

С помощью бэкдоров в процессоре, софтовых блобах и т.п.?

Можно ли как-то минимизировать возможность создания writable FS в обычном Linux? Убрать дрова для loopback, ramdrive, etc. ? Оставить только минимум дров, вкомпиленных в ядро без возможности загружать другие? Монтировать только readonly FS на readonly CDROM? Kernel lockdown=confidentiality ?

Как у вас достигается невозможность создания левых executable? У вас есть какая-то FS?

А как их получить?

Можно у админа узнать например:) Ну или через бэкдор, разработчик (или техподдержка) может оставить себе какой то канал для настройки системы, даже если все цивилизованно и действительно никакие данные пользователей не смотрет.

Можно ли как-то минимизировать возможность создания writable FS в обычном Linux? Убрать дрова для loopback, ramdrive, etc. ? Оставить только минимум дров, вкомпиленных в ядро без возможности загружать другие? Монтировать только readonly FS на readonly CDROM? Kernel lockdown=confidentiality ?

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

Как у вас достигается невозможность создания левых executable? У вас есть какая-то FS?

Если все библиотеки и приложения слинковать в один образ, у каждого символа будет уникальный адрес не совместимый с другими конфигурациями. Для того чтобы что то запустить «из вне» как минимум нужно знать набор этих адресов. Плюс если у вас есть внутренняя «файловая» система в которой по сути дела перечисленны все идентификаторы возможных входов утилит, то вам не нужен механизм запуска внешних приложений, вы можете только этим списком ограничится.

Файловая система естественно есть, на основе VFS, и даже можно подключить аналог ‘/bin’, и можно подключать различные типы файловых систем, например только для конфигурации https://habr.com/ru/company/embox/blog/573244/ просто если не разрешено исполнение бинарников, то и добавить ничего нельзя.

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

В каком смысле слинковать? Речь о статической сборке объектных файлов и библиотек в один бинарный файл, которому можно передать управление (CPU может сделать jmp куда-то внутрь него)? У вас вероятно нет даже загрузчиков в общепринятом смысле для ELF и т.п.?

Для того чтобы что то запустить «из вне» как минимум нужно знать набор этих адресов. Плюс если у вас есть внутренняя «файловая» система в которой по сути дела перечисленны все идентификаторы возможных входов утилит, то вам не нужен механизм запуска внешних приложений, вы можете только этим списком ограничится.

Как подобного добиться в обычных дистрибутивах типа Alpine, если вырезать и поотключать лишнее? Unikernel вероятно предоставляет что-то подобное?

У вас вероятно нет даже загрузчиков в общепринятом смысле для ELF и т.п.?

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

Как подобного добиться в обычных дистрибутивах типа Alpine, если вырезать и поотключать лишнее?

До определенной степени Alpine или другие дистрибутивы ориентированные на встроенные системы, этим и занимаются. Но это вся таки решение -защитить универсальную ОС, то есть добавить к ней средства безопасности. Тут идея, что не делать универсальную ОС, а сделать специализированную, тогда и защищать прийдется гораздо меньше.

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

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

что можно про это прочитать — так чтобы с высоты птичьего полета ознакомиться?

респект, если что Спасибо

что можно про это прочитать — так чтобы с высоты птичьего полета ознакомиться?

Есть открытый проект на github (https://github.com/embox/embox )

Документация, в том числе и русский мануал для начала (https://github.com/embox/embox-docs/releases)

Ну и наверное самое информативное это блог на хабре (https://habr.com/ru/company/embox/blog/)