> Разграничить доступность коду только определённой областью доступа
> было нужно и вчера и сегодня, и будет нужно всегда.Да, но не для кода драйверов, либо с точки зрения защиты от классов атак, не приводящих сразу к выполнению произвольного кода, либо как hardening, а не как надежный механизм защиты.
Если же произвольный код уже выполняется, то при доступе такого кода к устройству, поддерживающему DMA, и отсутствии IOMMU, через это устройство можно ограничение на доступ к определенной области памяти обойти (попросить устройство записать/считать куда/откуда хочется).
Но я согласен, что Joanna излишне категорична в процитированном мной утверждении.
> И дрова устройств - лишь частный случай такого кода.
Да.
> (а у x86 процов, кстати, есть аж 4 уровня защиты (protectiong rings) в защищённом
> режиме, и в самых распространённых ядрах/осях почему-то 2 средних были не
> у дел... а ведь это потенциал безопасности...)
По-моему, потенциала там почти нет. Два разных ring 3 процесса (или нити в микроядре) могут быть разделены друг от друга не хуже, чем будучи на разных кольцах. Раз кольца есть, ими можно пользоваться, но и без них было бы почти так же. Вот о моем опыте применения ring 2 не по назначению, и еще о кольцах на не-x86:
https://www.linux.org.ru/news/hardware/11636749#comment-1163...
> Несколько голословно (но текст я прочитать не асилил). Попробую взять логически.
> Есть монолит ядро, и в нём есть драйвер сетевухи. Этот драйвер может
> причинить много "пользы" внутри всего ядра, ибо монолит.
> Если же сей код ограничить каким-то пространством доступа - то безопасности:
> * добавится?
> * убавится?
> * не изменится?
> Думаю, ответ очевиден. Следовательно, "no security benefit" != true
Ответ не очевиден. С точки зрения перфекциониста, если драйвер всё равно может запросить у сетевухи DMA куда угодно, "не изменится". С точки зрения практика, скорее всего, "добавится", т.к. атаки станут сложнее, а более сложное менее надежно, что приведет к тому что меньший их процент достигнет успеха на конкретных системах в конкретных обстоятельствах. Также, часть классов атак и раньше не достигали бы выполнения произвольного кода сразу, и они могут оказаться полностью нейтрализованы. Возможно также, что безопасность "убавится", если реализация этого ограничения привнесет сложность в ядро, вместе с дополнительными багами.
В целом, я обычно за hardening, но "за" и "против" надо оценивать.
> Как насчёт драйвера мыльного аккаунта (Thunderbird)?
> Или приложения для фильтрации траффика (modprobe xtables)?
> И то, и другое - код. И то, и другое источник угроз
> безопасности. И то, и другое можно и нужно изолировать, предоставляя доступ
> лишь к необходимым для работы ресурсам.
Да.
> А то, что там "под капотом" у прокладки "разговора" с железом (PIO,
> DMA, IOMMU) - это уже нюансы. У микроядра всё равно есть
> некоторая базовая часть-загрузчик-менеджер (собственно, МИКРО-ядро). И если нет IOMMU,
> то в помощь приложениям-драйверам будет подсистема ввода-вывода в этом микроядре (точно
> также, как и управление памятью тоже будет там). Приложения-дрова делают запрос/ответ
> об I/O не сами, а просят об этом микроядро. Медленнее, чем
> монолит, но профит очевиден.
Часть проблемы в том, что то, как к конкретному устройству делать запрос об I/O, отличается между устройствами, а значит плохо ложится в такую универсальную прослойку - она снова становится "монолитным ядром", содержащим в себе кусочки кода, специфичные для драйверов разных устройств. Фактически мы получаем разграничение привилегий между частями каждого отдельного драйвера. Наверное, это можно реализовать хорошо, сильно убавив размер этой монолитной прослойки по сравнению с общим размером ядра.
P.S. Вижу, кто-то тут "заминусовал" сообщения выше по треду. По-моему, у нас нормальная дискуссия по теме, и минусы тут ни к чему, т.к. все сообщения являются "сигналом", а не "шумом", несмотря на чуточку разные мнения.
