Основное что требуется — изоляция и полный контроль всех взаимодействий. Конечно, можно было бы пойти по пути доработки существующего микроядра. Если бы мы начинали писать ОС сейчас, то, возможно, взяли бы за базу тот же 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.
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.