В Windows, Linux, iOS и многих других популярных в настоящее время ОС есть фундаментальные проблемы с безопасностью, например, очень большие ядра и соответственно поверхность атаки на них. Эти проблемы крайне сложно решить эволюционными изменениями. Т.к. спрос на безопасность растет, они будут постепенно вытеснены более современными системами (основанными на других подходах, например MILS). Тренд видно уже сейчас, например, новые операционными системы общего назначения от Google (Fuchsia) и Huawei (Harmony/Hong Meng) не имеют ничего общего с Linux и используют в своей основе микроядра. Рискну предположить, что через 10 лет Android или его преемник будет работать не на Linux.
Без обид, но основной тезис статьи высосан из пальца. Вопрос не в том, кто лучше Linux или Windows, а в том, что обе системы технически безнадежно устарели. Шило на мыло в MS образца 2020 года менять дураков нет, это уже не та компания.
Еще доставляет в этой игре блог разработчиков и описание того, как они оптимизируют двигло. Несмотря на кажущуюся простоту и олдскульность, игроки строят такие гигантские фабрики, что вопрос производительности далеко не праздный. Такое внимание к памяти, локальности данных и алгоритмам не часто встретишь в играх, мое уважение разработчикам.
Корректность работы гипервизора как ядра разделения тоже по хорошему доказывать нужно. Например, для Hyper-V это немцы делали, в процессе родился интересный тул VCC. В целом гипервизор не особо что дает по сравнению с микроядром в плане изоляции и пихать его бездумно в IoT смысла нет. А вот если, например, есть желание андроид запускать в отдельной партиции, вот тогда да.
Сразу предупреждаю, он достаточно сырой и основан на не самой свежей версии. Мы про него специально не писали в статье, во-первых он достоин отдельной публикации, во-вторых хотим выпустить новую редакцию.
Нет, поддержка E2K пока не планируется. Архитектура интересная, но компилятор AFAIK закрытый и поддержать её будет не просто.
Основное что требуется — изоляция и полный контроль всех взаимодействий. Конечно, можно было бы пойти по пути доработки существующего микроядра. Если бы мы начинали писать ОС сейчас, то, возможно, взяли бы за базу тот же seL4. Проделанная работа по верификации вызывает уважение. Но KasperskyOS начал разрабатываться задолго до публикации исходного кода seL4. Тогда вариантов было намного меньше. Сейчас мы уже много вложили в собственную разработку и смысла переходить на что-то другое не видим.
1. В основном пишем мы сами. Но бывает что пишут и партнеры. Документации по всем классам устройств не всегда хватает, мы над этим работаем.
2. Здесь wiz ответил. В будущем систему работы с 3rd party пакетами хотелось бы сделать более открытой, т.ч. бы партнерам было проще добавлять новые пакеты и результаты работы были бы доступны всем (если, конечно, партнер не против их опубликовать).
3. Мобильный телефон — это уже очень близко к ОС общего назначения. Но на десктопы и серверный сегмент мы сейчас не целимся.
4. По разному бывает. Есть большой SDK для разработки решений на базе KasperskyOS. Если партнер хочет позиционировать свой продукт как «иммунное» решение, то мы так же помогаем с определением целей безопасности и архитектуры решения, написанием политик, можем делать пен-тестирование. Т.е. это помощь с контролем качества, так что бы не получилось, что используя бренд Лаборатории и активность компании по продвижению кибер-иммунитета партнеры не выпускали совсем дырявые поделки. Есть отраслевые SDK с проработанной архитектурой решения, моделью приложений, написанными политиками безопасности. Хороший пример такого SDK — платформа AUTOSAR Adaptive Platform. Готовится похожие решения для IoT, мобильной платформы. Конкретные условия стоит обсуждать с бизнес-подразделением.
Насчет открытия исходников — в статье мы уже говорили, что рассматриваем такую возможность. С замечанием о основной ценности в бумажке о наличии в реестре отечественного ПО не соглашусь (об этом же реестре речь?). Основные деньги Лаборатория зарабатывает не в России и переориентировать бизнес на работу только на рынке РФ планов не строит.
Основное что требуется — изоляция и полный контроль всех взаимодействий. Конечно, можно было бы пойти по пути доработки существующего микроядра, сделать его пригодным для работы Kaspersky Security System. Если бы мы начинали писать ОС сейчас, то, возможно, взяли бы за базу тот же seL4. Проделанная работа по верификации вызывает уважение. Но KasperskyOS начал разрабатываться задолго до публикации исходного кода seL4. Тогда вариантов было намного меньше. Сейчас мы уже много вложили в собственную разработку и смысла переходить на что-то другое не видим.
1. У нас поддерживается два сетевых стека, один, полнофункциональный, основан на NetBSD, второй — lwIP. Из файловых систем — ext2, fat, jffs2, ведется работа над портом btrfs.
2. Модель «Rendezvous», которая используется у нас для IPC, вполне пригодна для realtime применений. Если требуется, можно выдать процессу права на доступ к конкретному региону физической памяти (и только к нему), поддерживается IOMMU. Если все сделать правильно, то такое решение будет и «кибериммунно» и производительно. Мы сейчас не целимся в решения, где нужна максимально возможная производительность, рано еще, но это не значит, что с производительностью у нас все плохо по определению.
3. См. ответ wiz. Мы работаем над доказательствами корректности сгенерированного Kaspersky Security System кода. Но компилятор С у нас вполне обычный — поддерживаем gcc и clang.
4. Мы не только код на С умеем генерировать из политики безопасности. Есть еще генерация моделей, например. Плюс сертификация.
5. У нас пока нет формального доказательства эквивалентности кода и модели. Но, например, имея модель можно сгенерировать 100% тестовое покрытие, которое проверит соответствие кода модели.
Помимо того, что это большой и толстый гипервизор Xen, в Qubes OS отсутствуют средства контроля взаимодействий. В целом у них подход существенно менее строгий и системный, не просто так у них слоган reasonably secure operating system.
Код KasperskyOS планируется сделать доступным для аудита в рамках Global Transparency Initiative.
Поддержка BTRFS — это круто, но так заморачиваться с загрузочным сектором мб и не стоило. Реальные системы (да и виртуалки) используют UEFI и там всегда есть бутовый раздел на FAT где можно разместить freeldr.
У ETW/WPA только один недостаток — нет микроархитектурных данных. Иногда нужно видеть зарежки при доступе к памяти, проблемы с предсказанием ветвлений.
Это как сказать. Да, можно авторизовать по магнитной полосе, но так же легко можно сделать charge back и вернуть себе деньги назад по операции с картой. А авторизация по PIN'у дает банку право считать, что транзакцию сделал лично ты и хрен чего докажешь. Перепрошить торговый терминал для сохранения PIN'ов (или поставить в нужном месте камеру) — не rocket science. Поэтому что безопаснее — вопрос спорный.
Зачем человека заминусовали? Да, проблема в не патчах, но добавление KPTI существенно затронуло менеджер памяти Windows. Вполне нормальное предположение, что это регресс, особенно учитывая эпичное фиаско с Windows 7.
os.kaspersky.ru/development/download
Сразу предупреждаю, он достаточно сырой и основан на не самой свежей версии. Мы про него специально не писали в статье, во-первых он достоин отдельной публикации, во-вторых хотим выпустить новую редакцию.
Нет, поддержка E2K пока не планируется. Архитектура интересная, но компилятор AFAIK закрытый и поддержать её будет не просто.
2. Здесь wiz ответил. В будущем систему работы с 3rd party пакетами хотелось бы сделать более открытой, т.ч. бы партнерам было проще добавлять новые пакеты и результаты работы были бы доступны всем (если, конечно, партнер не против их опубликовать).
3. Мобильный телефон — это уже очень близко к ОС общего назначения. Но на десктопы и серверный сегмент мы сейчас не целимся.
4. По разному бывает. Есть большой SDK для разработки решений на базе KasperskyOS. Если партнер хочет позиционировать свой продукт как «иммунное» решение, то мы так же помогаем с определением целей безопасности и архитектуры решения, написанием политик, можем делать пен-тестирование. Т.е. это помощь с контролем качества, так что бы не получилось, что используя бренд Лаборатории и активность компании по продвижению кибер-иммунитета партнеры не выпускали совсем дырявые поделки. Есть отраслевые SDK с проработанной архитектурой решения, моделью приложений, написанными политиками безопасности. Хороший пример такого SDK — платформа AUTOSAR Adaptive Platform. Готовится похожие решения для IoT, мобильной платформы. Конкретные условия стоит обсуждать с бизнес-подразделением.
1. У нас поддерживается два сетевых стека, один, полнофункциональный, основан на NetBSD, второй — lwIP. Из файловых систем — ext2, fat, jffs2, ведется работа над портом btrfs.
2. Модель «Rendezvous», которая используется у нас для IPC, вполне пригодна для realtime применений. Если требуется, можно выдать процессу права на доступ к конкретному региону физической памяти (и только к нему), поддерживается IOMMU. Если все сделать правильно, то такое решение будет и «кибериммунно» и производительно. Мы сейчас не целимся в решения, где нужна максимально возможная производительность, рано еще, но это не значит, что с производительностью у нас все плохо по определению.
3. См. ответ wiz. Мы работаем над доказательствами корректности сгенерированного Kaspersky Security System кода. Но компилятор С у нас вполне обычный — поддерживаем gcc и clang.
4. Мы не только код на С умеем генерировать из политики безопасности. Есть еще генерация моделей, например. Плюс сертификация.
5. У нас пока нет формального доказательства эквивалентности кода и модели. Но, например, имея модель можно сгенерировать 100% тестовое покрытие, которое проверит соответствие кода модели.
Код KasperskyOS планируется сделать доступным для аудита в рамках Global Transparency Initiative.