Зефир и Фуксия идут разными путями к безопасности

На недавнем саммите по безопасности Linux исследователи компьютеров АНБ рассказали о своем вкладе в код безопасности в ОС Zephyr и Fuchsia.
Каждый стек безопасности значительно отличается друг от друга и от Linux.

Если вы относитесь к тому типу людей, которые используют слово «vuln» в качестве сокращения для уязвимостей кода, вам следует ознакомиться с презентацией недавнего саммита по безопасности Linux под названием «Безопасность в Зефире и Фуксии». В своем выступлении два исследователя из Агентство национальной безопасности обсуждает их вклад в зарождающиеся стеки безопасности двух проектов ОС с открытым исходным кодом: Zephyr и Fuchsia.

Если вы беспокоитесь о том, что старый работодатель Эдварда Сноудена помогает писать операционные системы следующего поколения, которые могли бы запустить нашу жизнь через 10 лет, рассмотрите положительные стороны.
Во-первых, так как это проекты с открытым исходным кодом, любые гнусные бэкдоры будут четко видны.
Во-вторых, АНБ знает кое-что о безопасности.
Стивен Смолли и Джеймс Картер, которые обсуждали безопасность в Zephyr и Fuchsia соответственно, являются исследователями компьютерной безопасности в исследовательской группе NSA Information Assurance Research, которая разработала и поддерживает дистрибутивы SELinux и SE Android с улучшенной безопасностью.
Смолли возглавляет NSA Security Enhancements (SE) для проекта Internet of Things и поддерживает ядро ​​и пользовательское пространство для SELinux.


Стивен Смолли (слева) и Джеймс Картер, исследователи из исследовательской группы АНБ по информационному обеспечению

(щелкните изображение, чтобы увеличить)

Linux Foundation, в котором находится Zephyr Project , который создает IoT-ориентированную Zephyr RTOS, является более зрелым из двух проектов.
У Google Fuchsia OS есть более длинный путь, особенно если вы считаете, что Fuchsia заменит Android и Chrome OS в течение следующего десятилетия.

Разработчики Zephyr и Fuchsia имеют редкую возможность с нуля разрабатывать новые, современные стеки безопасности.
Одна из главных причин, по которой Google решил построить Fuchsia из нового микроядра, заключалась в том, что она могла избежать мешанины с унаследованным кодом, наложенным поверх Linux, тем самым улучшив безопасность.
Попытки повысить безопасность в Linux всегда будут походить на исправление дыр в лодке.
Zephyr и Fuchsia стремятся быть эквивалентами ОС на воздушной подушке.

Zephyr и Fuchsia - очень разные ОС, и они по-разному реализуют безопасность.
Zephyr предназначен для ограниченных устройств, работающих на микроконтроллерах, таких как чипы Cortex-M4, тогда как Fuchsia будет ориентироваться на телефоны и настольные компьютеры, работающие на процессорах приложений, таких как Cortex-A53 и Intel Core.

«Zephyr и Fuchsia были открыты в 2016 году, но они были разработаны для очень разных вариантов использования», - сказал Смолли.
«Их архитектура очень отличается, и каждая из них также сильно отличается от Linux».

Зефир безопасности

Как и Linux и Fuchsia, Zephyr имеет защиту памяти RO / NX, предотвращение переполнения стека и обнаружение переполнения буфера стека.
Тем не менее, до сих пор нет ядра или пользовательского пространства ASLR (рандомизация размещения адресного пространства), который «скорее всего перейдет к рандомизации времени сборки и небольшому перемещению времени загрузки», сказал Смолли.

Среди других архитектурных различий с Linux: «В Zephyr нет изоляции процессов, есть только модель потоков в пользовательском пространстве», - объяснил Смолли.
«Модель абстракции процесса еще не реализована, и граница ядра / пользователя все еще не определена».


Стивен Смолли объясняет различия между Zephyr (левая колонка) и безопасностью Linux

(щелкните изображение, чтобы увеличить)

В Zephyr «вы обычно работаете с одним приложением, и безопасность в значительной степени зависит от конкретных SoC и конфигураций ядра», - сказал Смолли.
Для сравнения: «В Linux есть ряд основных функций безопасности ОС, которые являются нейтральными и независимыми».

По словам Смолли, в оригинальной версии Zephyr был один исполняемый файл с единым адресным пространством со всеми потоками в режиме супервизора и без защиты памяти или виртуальной памяти.
«Поскольку Zephyr добавил защиту ОС, он стремился минимизировать изменения в API ядра, чтобы быть обратно совместимым», - добавил он.
«Ключевая философия проектирования Zephyr - делать как можно больше во время сборки, а затем как можно больше во время последнего просмотра, минимизируя таким образом накладные расходы времени выполнения и обеспечивая ограниченную задержку для реального времени».

Безопасность Zephyr осложняется тем фактом, что некоторые целевые блоки MCU включают блоки защиты памяти (MPU), а другие - нет.
Начиная с версий 1.8 и 1.9, Zephyr начал обеспечивать защиту памяти с учетом обоих типов микроконтроллеров.

Команда NSA разработала набор тестов защиты памяти ядра по образцу тестов lkdtm из проекта самозащиты ядра (KSPP) для Linux.
«Тесты помогли выявить ошибки в драйверах Zephyr MPU, и теперь они используются для регрессионного тестирования», - сказал Смолли.

Zephyr добавил поддержку пользовательского пространства в версиях 1.10 и 1.11, которая обеспечивала базовую поддержку потоков пользовательского режима с изолированной памятью.
Команда Смолли разработала набор тестов пользовательского пространства, «которые пытались проверить свойства безопасности для потоков пользовательского режима». Модель памяти пользовательского пространства Zephyr по-прежнему ограничена одним исполняемым файлом и адресным пространством, а виртуальной памяти нет.
«Он может поддерживать потоки пользовательского режима, но не полные процессы», - объяснил Смолли.

Функции безопасности Zephyr включают модель разрешений объекта, в которой пользовательским потокам сначала должны быть предоставлены разрешения для объекта, чтобы разрешить доступ.
«Поток режима ядра может предоставлять доступ к потоку режима пользователя, а механизм наследования позволяет распространять эти разрешения вниз», - объяснил Смолли.
«Это модель« все или ничего »- все пользовательские потоки могут получить доступ ко всем глобальным переменным приложения».

Этот подход «все или ничего» «ложится тяжелым бременем на разработчика приложений, которому приходится вручную организовывать компоновку глобальной переменной памяти приложения, чтобы соответствовать ограничениям MPU», - сказал Смолли.
Чтобы компенсировать это, команда АНБ в версии 1.13 разработала функцию, которая «поддерживает несколько более удобный для разработчиков способ группировки глобалов приложений на основе требуемой защиты.
Это маленький шаг вперед, а не панацея ».

Будущая работа по обеспечению безопасности Zephyr включает в себя добавление виртуализации MPU, которая «позволит нам поддерживать большее количество регионов, а не только восемь, которые могут быть заменены на MPU по требованию», - сказал Смолли.
«Мы также надеемся обеспечить полную поддержку нескольких приложений и загрузку программ».

В Zephyr код ядра полностью доверен.
«Мы хотели бы увидеть, как Linux смягчает уязвимости ядра, используя функции самозащиты ядра KSPP, минимизируя при этом издержки времени выполнения», - сказал Смолли.
Другие пункты списка пожеланий включают использование armv8-m для микроконтроллеров Cortex-M, что обеспечивает безопасность TrustZone.
Существует также долгосрочный план «разработать MAC, подходящий для ОСРВ, который больше ориентирован на разбиение приложений во время сборки».

Фуксия безопасности

Fuchsia отличается от Linux и Zephyr тем, что это микроядерное ОС с защитой, основанной на объектных возможностях.
Как и Linux, он предлагает изоляцию процессов.
Кроме того, «существует система ASLR для ядра или пользовательского пространства», - сказал Джеймс Картер из АНБ.

По сравнению с «большим и монолитным» Linux, Fuchsia имеет маленький, разложенный TCB (база доверенных вычислений) », - сказал Картер.
«Он также использует возможности объекта вместо ЦАП и MAC».

Fuchsia основана на микроядре Zircon, которое происходит от маленького ядра (lk), «ОСРВ, используемой в загрузчике Android», объяснил Картер.
Fuchsia расширяет возможности lk для поддержки 64-разрядных, пользовательского режима, процессов, IPC и других расширенных функций.
«LK - единственное, что работает в режиме супервизора.
Драйверы, файловая система и сеть работают в режиме пользователя ».

Механизмы безопасности Fuchsia включают обычные маркеры и маркеры ресурсов, использующие возможности объекта Zircon.
«Обычные дескрипторы обычно являются единственным способом, которым пользовательское пространство может получить доступ к объектам ядра», - сказал Картер.
«Fuchsia отличается от большинства операционных систем тем, что в ней используется push-модель, в которой клиент создает дескриптор и передает его на сервер.
Дескрипторы являются процессными и не поддающимися обработке, и они идентифицируют как объект, так и набор прав доступа к объекту.
Права доступа включают дублирование их с равными или меньшими правами или передачу их через IPC или использование их для получения дескрипторов дочерних объектов с равными или меньшими записями ».

Фуксия обрабатывает «хорошо, потому что они разделяют права на распространение и использование и разделяют права на различные операции», сказал Картер.
«Вы также можете уменьшить права путем дублирования дескрипторов».

Однако ручки все еще создают некоторые проблемы.
Например, «с помощью object_get_child (), если у вас есть дескриптор задания, вы можете получить дескриптор чего-либо в этой работе или дочерних заданиях», - сказал Картер.
«Кроме того, утечка корневого дескриптора является фатальной для безопасности.
Мы хотели бы видеть больше работы по обеспечению того, чтобы все могло быть наименее привилегированным, и больший контроль над распространением и отзывом дескрипторов.
Не все операции в настоящее время проверяют права доступа, а некоторые права не реализованы ».

Дескрипторы ресурса, которые являются типом дескриптора, используемого для ресурсов платформы, таких как ввод-вывод с отображением памяти, порты ввода-вывода и IRQ, позволяют разработчикам указывать тип ресурса и необязательный диапазон.
С другой стороны, они предлагают «мелкозернистые, иерархические ограничения ресурсов», сказал Картер.
«Однако сейчас проверка корневых ресурсов не очень детализирована, и, как и в случае с обычными дескрипторами, утечки могут быть фатальными.
Нам нужно работать над распространением, отзывом и переработкой с минимальными привилегиями ».

Примитивы безопасности Zircon включают политику работы и применение vDSO.
«В Фуксии все является частью работы», - сказал Картер.
«У процессов нет дочерних процессов - у рабочих мест есть дочерние.
Задания могут быть вложенными, содержать задания и другие процессы, а политика заданий применяется ко всем процессам в задании.
Политики наследуются от родителей и могут быть сделаны только более строгими ».

Со стороны профессионалов, вы можете создавать детализированные политики создания объектов, а также иерархические смешанные политики заданий », - пояснил Картер.
«Однако политика W ^ X еще не реализована, и когда она возникнет, это вызовет проблемы со строгой иерархической политикой, потому что, если ребенку нужно отобразить что-то W ^ X, тогда все предки должны будут сопоставить это бета-отображение W ^ X как Что ж."

В Fuchsia примитив vDSO (виртуальный динамический общий объект) «предназначен только для вызова системных вызовов», сказал Картер.
«Он полностью доступен только для чтения и привязан к ядру».

VDSO от Fuchsia делает ОС более безопасной, «ограничивая поверхность атаки ядра, обеспечивая использование общедоступного API и поддерживая ограничения на системные вызовы для каждого процесса», - сказал Картер.
«Также хорошо, что ядру не доверяют vDSO, поэтому его аргументы системного вызова полностью проверены». С другой стороны, текущая версия предлагает возможность вмешательства или обхода vDSO, добавил Картер.


Джеймс Картер обсуждает пространства имен и песочницы в Фуксии

(щелкните изображение, чтобы увеличить)

Картер продолжал объяснять пространства имен и песочницы Фуксии.
Преимущества реализации пространств имен включают «отсутствие глобального пространства имен и тот факт, что достижимость объекта определяется начальным пространством имен», сказал Картер.
«Но мы хотели бы видеть больше детализации». Для песочниц, которые используются для изоляции приложений: «Мы хотели бы видеть расширение до системных сервисов.
Также нет независимой проверки конфигурации песочницы ».

Как и в случае с Zephyr, команда NSA рекомендует, чтобы Fuchsia в конечном итоге добавила инфраструктуру MAC, которая помогла бы «контролировать распространение, поддерживать отзыв и применять минимальные привилегии», сказал Картер.
«MAC может поддерживать более точную проверку и обобщать политику заданий, а также проверять пространства имен и песочницы.
Он также может предоставить унифицированную структуру для определения, обеспечения и проверки целей безопасности ».

По словам Картера, варианты интеграции MAC с Fuchsia начинаются с создания его полностью в пространстве пользователя без поддержки микроядра.
В качестве альтернативы вы могли бы «расширить существующий механизм», создав его «в основном в пространстве пользователя с ограниченной поддержкой микроядра». Третий вариант - «создать логику политики безопасности в пространстве пользователя с полным применением микроядра для его объектов, как мы это делали с DTMach в SELinux ».

В заключение Картер подчеркнул, что стек безопасности Fuchsia находится в стадии разработки.
«Мы просто пытаемся оценить вещь». Вы можете посмотреть все видео ниже.

Презентация «Безопасность в Зефире и Фуксии» на Саммите по безопасности Linux в 2018 году

Эта статья защищена авторским правом © 2018 Linux.com и была первоначально опубликована здесь .
Он был воспроизведен этим сайтом с разрешения его владельца.
Пожалуйста, посетите Linux.com для получения последних новостей и статей о Linux и open source.