Второй день конференции оказался даже более насыщенным интересными докладами, чем первый. На стенде «Лаборатории Касперского» не иссякал поток желающих взломать сейф и получить мерч. Правильно настроить для этого политики KasperskyOS смогли 7 человек. Большой ажиотаж вызвал турнир по Quake — игра работала на тонком клиенте под управлением нашей операционки. В отстреле монстров поучаствовали около 30 человек. Впрочем, основные события конференции происходили на главной сцене РЭУ им. Плеханова.
День открылся круглым столом «Безопасность операционным систем в контексте искусственного интеллекта», организованным «Лабораторией Касперского». На нем представители ведущих ИТ-компаний обсудили, как искусственный интеллект влияет на разработку, безопасность и архитектуру современных операционных систем. Дискуссия объединила экспертов из группы «Астра», «Базальт СПО», НПП «Криптософт», «Ред Софт» и других компаний.
Одним из ключевых вопросов стала трансформация роли программистов: если раньше простые задачи решали джуны, то теперь их все чаще отдают ИИ.
«Если ИИ решает все типовые задачи, на которых раньше учились джуны, кто вырастет в мидлов?» — задался вопросом модератор Андрей Духвалов, директор департамента перспективных технологий «Лаборатории Касперского».
«Бизнесу дешевле делегировать рутину ИИ, и джунам просто не останется задач для роста», — отметил Егор Смирнов, руководитель проектов по внедрению искусственного интеллекта «Ред Софт».
«Хорошая альтернатива — использовать ИИ не как замену, а как „второе мнение“. Джун пишет код — ИИ помогает проверить», — предложил Павел Мозгов, заместитель директора дирекции внедрения и сопровождения, группа «Астра».
Важную часть обсуждения заняли риски, связанные с безопасностью. В частности, функциональные угрозы ИИ — от отравления обучающих данных до промпт-инъекций.
«Одна отравленная картинка способна сломать всю модель. Это открывает злоумышленникам совсем новые возможности», — предупредил Егор Васин, специалист отдела технологий защиты вычислительных сетей НТП «Криптософт».
«Появились новые риски: промпт-инъекции, генерация эксплойтов. Это совсем другая безопасность», — добавил Константин Сорокин, руководитель исследовательской группы «ИИ в программной инженерии», ИСП РАН.
Кроме того, эксперты обсудили будущее взаимодействия ИИ и операционных систем.
«Через несколько лет интерфейс ОС — это просто окно с ИИ. Пользователь описывает задачу, ИИ генерирует под нее приложение», — предсказал Сергей Аносов, руководитель отдела продуктовой экспертизы «Открытая мобильная платформа»
«ИИ можно подключить даже к ядру ОС — например, чтобы умнее распределять ресурсы между процессами», — предложил Михаил Новоселов, ведущий системный инженер-программист, НТЦ ИТ РОСА.
«Для взаимодействия агентов в приложениях и ОС нужны общие стандарты и контекст», — подчеркнул Павел Мозгов из группы «Астра».
Отдельное внимание вызвала тема снижения стоимости атак.
«Сегодня атака стоит 600 тысяч евро. С ИИ эта цена упадет до 5. Он сам найдет уязвимость и напишет эксплойт», — заявил Сергей Аносов.
«ИИ теперь работает по обе стороны баррикад. Он усиливает защиту — но и упрощает взлом», — резюмировал Егор Смирнов.
Участники сошлись во мнении: ИИ уже перестает быть просто инструментом. Он становится новым участником технологической среды — со своими преимуществами, рисками и последствиями.
Денис Молодяков, ведущий разработчик департамента разработки сервисов мультимедиа «Лаборатории Касперского», выступил с докладом «Разработка DRM-совместимых дисплейных драйверов для микроядерной ОС». В нем он рассказал, как для KasperskyOS разрабатываются драйверы под интерфейс графического стека Linux. Молодяков снял некоторую часть опасений, касательно снижения производительности в микроядерной ОС. По его словам, временные штрафы в пользовательских сценариях незначительны. Более того, изоляция компонентов позволяет более гранулярно контролировать потоки данных и регулировать права доступа к ресурсам/сервисам через политики безопасности.
Безопасности касался и вопрос из зала:
В последнее время десятки уязвимостей, выявленных Google Project Zero, эксплуатируются через драйвер Mali GPU, что приводит к компрометации Android. Основная проблема в том, что графический драйвер работает в пространстве, доступном из sandbox, так как необходимо обеспечить работу пользовательского интерфейса.
Как в KasperskyOS решается задача защиты в подобных условиях, когда интерфейс должен быть доступен из непривилегированного контекста? Какие механизмы реализованы в системе — или что необходимо реализовать — чтобы в случае выполнения произвольного кода в GPU-драйвере это не привело к компрометации всей операционной системы?
Регламент конференции не позволил достаточно подробно ответить на этот вопрос, поэтому публикуем полный ответ Дениса Молодякова здесь.
Если говорить про атаки со стороны приложения, а вопросе шла речь именно про такие, то имеем следующую картину:
1. В KasperskyOS сам по себе драйвер изолирован от ядра. То есть компрометация драйвера не означает рут в ядре. По этому поводу есть отличная статья на Хабре от коллег.
2. Взаимодействие между компонентами графического стэка KasperskyOS (реализация OpenGL, драйвер GPU) контролируется политиками безопасности. Так, например, уязвимости вида CWE-300: Channel Accessible by Non-Endpoint и CWE-200: Exposure of Sensitive Information to an Unauthorized Actor перекрываются механизмом IPC вкупе с политиками безопасности.
3. Если же по какой-то причине, после всех барьеров, сам драйвер GPU был скомпрометирован, то тут надо учитывать нюансы аппаратной платформы. Если, например, в платформе есть устройство IOMMU, через которое ходит в память GPU, то это устройство обычно контролируется ядром. В таком случае, ядро контролирует домен памяти, к которому есть доступ у IOMMU и получить доступ к коду самого ядра, даже взломав драйвер, все равно не выйдет.
Про атаки со стороны GPU и контроль связанной с ним аппаратуры, лучше поговорить отдельно, это тема сама по себе очень сложная.
Доклад «Механизмы изоляции при реализации корня доверия. Интеграция с технологиями корня доверия в KasperskyOS» прочитал дуэт экспертов «Лаборатории Касперского».
Владимир Карантаев, менеджер по анализу эффективного использования аппаратных средств, сделал аналитический обзор существующих технологий Root of Trust. Он уделил особое внимание RISC-V как платформе для создания верифицируемых решений в области корней доверия и дал рекомендации по развитию RoT-экосистемы в РФ.
Практические аспекты рассмотрел Антон Рыбаков, руководитель группы разработки функций безопасности KasperskyOS. Он рассказал, как технологии корня доверия реализуются в KasperskyOS. Он же ответил и на вопрос из аудитории:
Вы говорите, что у вас в KasperskyOS все взаимодействия происходят через IPC. Если взять тот же Linux, то там тоже есть IPC. Вот, например в D-Bus нет никакой аутентификации. Через него можно отправлять что угодно. А у вас же Secure by Design. Как у вас защищены IPC? Что мешает низкопривилегированному пользователю через ваш IPC-канал что-то отправлять и получать ключи?
В KasperskyOS обеспечивается целостность исполняемых программных компонентов. У каждого компонента, который работает с IPC, есть определенный идентификатор. Монитор безопасности в ядре ОС при осуществлении вызова проверяет источник запроса на основе идентификатора процесса. Таким образом, подделать handle соединения и работать с IPC от имени другого процесса у нас невозможно. У низкопривилегированного пользователя также нет возможности сформировать произвольный IPC-запрос самому, потому что такого понятия просто нет у нас в системе.
Cергей Рогачев, руководитель отдела развития архитектуры KasperskyOS, дал более развернутый ответ для тех, кто интересуется деталями.
Про Linux и D-Bus. Не в защиту D-Bus: в нем есть механизм аутентификации, более того, их несколько. Первый основан на SO_PEERCRED и работает для локальных процессов, второй, менее надежный, применяется для удаленных процессов и использует SASL (RFC4422). Т. е. D-BUS и сервисы на этой шине знают, кто к ним обращается. Есть и механизм авторизации, основанный на PolicyKit: получив достоверную информацию о отправителе запроса, сервер обращается к PolicyKit за вердиктом. На практике большинство приложений в Linux-дистрибутивах в рамках сессии запускаются от одного пользователя, а следовательно, имеют схожие привилегии.
Про KasperskyOS. Здесь также работает аутентификация и авторизация. Ядро KasperskyOS всегда знает кто, кому и какой тип сообщения отправляет. Если IPC-вызов специально не разрешить в политике монитора безопасности, он будет заблокирован.
Монитор безопасности в ядре хранит достоверную информацию о каждом процессе: известны их идентификаторы, класс (eiid), методы, которые могут предоставляться сервисами, контексты с атрибутами безопасности. Политика, реализованная в мониторе, должна явно разрешить посылку конкретного сообщения (вызов метода) для обозначенных ядром отправителя, получателя и наборов атрибутов, ассоциированных с этими процессами, а также объектами, упомянутыми в сообщении. В противном случае работает решение «default deny». Сервисы могут самостоятельно обеспечивать более гранулярную авторизацию доступа к своим объектам через механизм OCAP.
OS DAY 2025 стал для «Лаборатории Касперского» отличной площадкой для обмена опытом, обсуждения вызовов и укрепления профессионального диалога вокруг безопасных систем.
Увидимся на мероприятии в следующем году!
Второй день конференции оказался даже более насыщенным интересными докладами, чем первый. На стенде «Лаборатории Касперского» не иссякал поток желающих взломать сейф и получить мерч. Правильно настроить для этого политики KasperskyOS смогли 7 человек. Большой ажиотаж вызвал турнир по Quake — игра работала на тонком клиенте под управлением нашей операционки. В отстреле монстров поучаствовали около 30 человек. Впрочем, основные события конференции происходили на главной сцене РЭУ им. Плеханова.
День открылся круглым столом «Безопасность операционным систем в контексте искусственного интеллекта», организованным «Лабораторией Касперского». На нем представители ведущих ИТ-компаний обсудили, как искусственный интеллект влияет на разработку, безопасность и архитектуру современных операционных систем. Дискуссия объединила экспертов из группы «Астра», «Базальт СПО», НПП «Криптософт», «Ред Софт» и других компаний.
Одним из ключевых вопросов стала трансформация роли программистов: если раньше простые задачи решали джуны, то теперь их все чаще отдают ИИ.
«Если ИИ решает все типовые задачи, на которых раньше учились джуны, кто вырастет в мидлов?» — задался вопросом модератор Андрей Духвалов, директор департамента перспективных технологий «Лаборатории Касперского».
«Бизнесу дешевле делегировать рутину ИИ, и джунам просто не останется задач для роста», — отметил Егор Смирнов, руководитель проектов по внедрению искусственного интеллекта «Ред Софт».
«Хорошая альтернатива — использовать ИИ не как замену, а как „второе мнение“. Джун пишет код — ИИ помогает проверить», — предложил Павел Мозгов, заместитель директора дирекции внедрения и сопровождения, группа «Астра».
Важную часть обсуждения заняли риски, связанные с безопасностью. В частности, функциональные угрозы ИИ — от отравления обучающих данных до промпт-инъекций.
«Одна отравленная картинка способна сломать всю модель. Это открывает злоумышленникам совсем новые возможности», — предупредил Егор Васин, специалист отдела технологий защиты вычислительных сетей НТП «Криптософт».
«Появились новые риски: промпт-инъекции, генерация эксплойтов. Это совсем другая безопасность», — добавил Константин Сорокин, руководитель исследовательской группы «ИИ в программной инженерии», ИСП РАН.
Кроме того, эксперты обсудили будущее взаимодействия ИИ и операционных систем.
«Через несколько лет интерфейс ОС — это просто окно с ИИ. Пользователь описывает задачу, ИИ генерирует под нее приложение», — предсказал Сергей Аносов, руководитель отдела продуктовой экспертизы «Открытая мобильная платформа»
«ИИ можно подключить даже к ядру ОС — например, чтобы умнее распределять ресурсы между процессами», — предложил Михаил Новоселов, ведущий системный инженер-программист, НТЦ ИТ РОСА.
«Для взаимодействия агентов в приложениях и ОС нужны общие стандарты и контекст», — подчеркнул Павел Мозгов из группы «Астра».
Отдельное внимание вызвала тема снижения стоимости атак.
«Сегодня атака стоит 600 тысяч евро. С ИИ эта цена упадет до 5. Он сам найдет уязвимость и напишет эксплойт», — заявил Сергей Аносов.
«ИИ теперь работает по обе стороны баррикад. Он усиливает защиту — но и упрощает взлом», — резюмировал Егор Смирнов.
Участники сошлись во мнении: ИИ уже перестает быть просто инструментом. Он становится новым участником технологической среды — со своими преимуществами, рисками и последствиями.
Денис Молодяков, ведущий разработчик департамента разработки сервисов мультимедиа «Лаборатории Касперского», выступил с докладом «Разработка DRM-совместимых дисплейных драйверов для микроядерной ОС». В нем он рассказал, как для KasperskyOS разрабатываются драйверы под интерфейс графического стека Linux. Молодяков снял некоторую часть опасений, касательно снижения производительности в микроядерной ОС. По его словам, временные штрафы в пользовательских сценариях незначительны. Более того, изоляция компонентов позволяет более гранулярно контролировать потоки данных и регулировать права доступа к ресурсам/сервисам через политики безопасности.
Безопасности касался и вопрос из зала:
В последнее время десятки уязвимостей, выявленных Google Project Zero, эксплуатируются через драйвер Mali GPU, что приводит к компрометации Android. Основная проблема в том, что графический драйвер работает в пространстве, доступном из sandbox, так как необходимо обеспечить работу пользовательского интерфейса.
Как в KasperskyOS решается задача защиты в подобных условиях, когда интерфейс должен быть доступен из непривилегированного контекста? Какие механизмы реализованы в системе — или что необходимо реализовать — чтобы в случае выполнения произвольного кода в GPU-драйвере это не привело к компрометации всей операционной системы?
Регламент конференции не позволил достаточно подробно ответить на этот вопрос, поэтому публикуем полный ответ Дениса Молодякова здесь.
Если говорить про атаки со стороны приложения, а вопросе шла речь именно про такие, то имеем следующую картину:
1. В KasperskyOS сам по себе драйвер изолирован от ядра. То есть компрометация драйвера не означает рут в ядре. По этому поводу есть отличная статья на Хабре от коллег.
2. Взаимодействие между компонентами графического стэка KasperskyOS (реализация OpenGL, драйвер GPU) контролируется политиками безопасности. Так, например, уязвимости вида CWE-300: Channel Accessible by Non-Endpoint и CWE-200: Exposure of Sensitive Information to an Unauthorized Actor перекрываются механизмом IPC вкупе с политиками безопасности.
3. Если же по какой-то причине, после всех барьеров, сам драйвер GPU был скомпрометирован, то тут надо учитывать нюансы аппаратной платформы. Если, например, в платформе есть устройство IOMMU, через которое ходит в память GPU, то это устройство обычно контролируется ядром. В таком случае, ядро контролирует домен памяти, к которому есть доступ у IOMMU и получить доступ к коду самого ядра, даже взломав драйвер, все равно не выйдет.
Про атаки со стороны GPU и контроль связанной с ним аппаратуры, лучше поговорить отдельно, это тема сама по себе очень сложная.
Доклад «Механизмы изоляции при реализации корня доверия. Интеграция с технологиями корня доверия в KasperskyOS» прочитал дуэт экспертов «Лаборатории Касперского».
Владимир Карантаев, менеджер по анализу эффективного использования аппаратных средств, сделал аналитический обзор существующих технологий Root of Trust. Он уделил особое внимание RISC-V как платформе для создания верифицируемых решений в области корней доверия и дал рекомендации по развитию RoT-экосистемы в РФ.
Практические аспекты рассмотрел Антон Рыбаков, руководитель группы разработки функций безопасности KasperskyOS. Он рассказал, как технологии корня доверия реализуются в KasperskyOS. Он же ответил и на вопрос из аудитории:
Вы говорите, что у вас в KasperskyOS все взаимодействия происходят через IPC. Если взять тот же Linux, то там тоже есть IPC. Вот, например в D-Bus нет никакой аутентификации. Через него можно отправлять что угодно. А у вас же Secure by Design. Как у вас защищены IPC? Что мешает низкопривилегированному пользователю через ваш IPC-канал что-то отправлять и получать ключи?
В KasperskyOS обеспечивается целостность исполняемых программных компонентов. У каждого компонента, который работает с IPC, есть определенный идентификатор. Монитор безопасности в ядре ОС при осуществлении вызова проверяет источник запроса на основе идентификатора процесса. Таким образом, подделать handle соединения и работать с IPC от имени другого процесса у нас невозможно. У низкопривилегированного пользователя также нет возможности сформировать произвольный IPC-запрос самому, потому что такого понятия просто нет у нас в системе.
Cергей Рогачев, руководитель отдела развития архитектуры KasperskyOS, дал более развернутый ответ для тех, кто интересуется деталями.
Про Linux и D-Bus. Не в защиту D-Bus: в нем есть механизм аутентификации, более того, их несколько. Первый основан на SO_PEERCRED и работает для локальных процессов, второй, менее надежный, применяется для удаленных процессов и использует SASL (RFC4422). Т. е. D-BUS и сервисы на этой шине знают, кто к ним обращается. Есть и механизм авторизации, основанный на PolicyKit: получив достоверную информацию о отправителе запроса, сервер обращается к PolicyKit за вердиктом. На практике большинство приложений в Linux-дистрибутивах в рамках сессии запускаются от одного пользователя, а следовательно, имеют схожие привилегии.
Про KasperskyOS. Здесь также работает аутентификация и авторизация. Ядро KasperskyOS всегда знает кто, кому и какой тип сообщения отправляет. Если IPC-вызов специально не разрешить в политике монитора безопасности, он будет заблокирован.
Монитор безопасности в ядре хранит достоверную информацию о каждом процессе: известны их идентификаторы, класс (eiid), методы, которые могут предоставляться сервисами, контексты с атрибутами безопасности. Политика, реализованная в мониторе, должна явно разрешить посылку конкретного сообщения (вызов метода) для обозначенных ядром отправителя, получателя и наборов атрибутов, ассоциированных с этими процессами, а также объектами, упомянутыми в сообщении. В противном случае работает решение «default deny». Сервисы могут самостоятельно обеспечивать более гранулярную авторизацию доступа к своим объектам через механизм OCAP.
OS DAY 2025 стал для «Лаборатории Касперского» отличной площадкой для обмена опытом, обсуждения вызовов и укрепления профессионального диалога вокруг безопасных систем.
Увидимся на мероприятии в следующем году!
Подпишитесь на наши сообщества и получите ссылку на дистрибутив в чате
